GitLab 17.9 Release

GitLab 17.9 released with GitLab Duo Self-Hosted available in GA

GitLab 17.9 released with GitLab Duo Self-Hosted available in GA,the ability to run multiple GitLab Pages sites with parallel deployments, the option to add project files to Duo Chat in VS Code and JetBrains IDEs, automatic deletion of older pipelines and much more!

Today, we are excited to announce the release of GitLab 17.9 with GitLab Duo Self-Hosted available in GA, the ability to run multiple GitLab Pages sites with parallel deployments, the option to add project files to Duo Chat in VS Code and JetBrains IDEs, automatic deletion of older pipelines and much more!

These are just a few highlights from the 110+ improvements in this release. Read on to check out all of the great updates below.

To the wider GitLab community, thank you for the 322 contributions you provided to GitLab 17.9! At GitLab, everyone can contribute and we couldn't have done it without you!

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Salihu Dickson

We’re excited to recognize Salihu Dickson as our MVP for his outstanding contributions to developing Comments on Wiki pages, a highly-requested feature that gathered over 200 positive reactions from the community!

His dedication spanned over six months, delivering an implementation of wiki top-level discussions with nearly 4,000 lines of code. Salihu also created several proof-of-concept implementations and improved the Wiki experience with additional features and bug fixes.

“Salihu has been an outstanding Community Contributor in developing Comments on Wiki pages!” shares Matthew Macfarlane, Product Manager, Plan:Knowledge at GitLab. “Salihu’s extensive knowledge of the product has allowed us to deliver this key feature more efficiently. As a Product Manager, it is a joy to work with contributors like Salihu!”

“An incredible achievement!” shares Alex Fracazo, Senior Product Designer, Plan:Knowledge at GitLab. “Salihu didn’t just build the basic functionality, but delivered a comprehensive end-to-end feature from top-level discussions on Wiki pages to error handling and test coverage.” Many members of the GitLab team showed strong appreciation for Salihu’s work, including Natalia Tepluhina, Principal Engineer, Vue.js core team member, and Vladimir Shushlin, Engineering Manager, Plan:Knowledge at GitLab, highlighting his technical skills and collaboration.

Salihu, a front-end engineer at Elixir Cloud and two-time GSoC mentor, shared - “I’d like to thank everyone who worked closely with me to make this possible. A special thank you to Himanshu Kapoor (Staff Frontend Engineer, Plan:Knowledge at GitLab) - your mentorship over the past few months has been instrumental to all the work I’ve done here, and I truly appreciate all the guidance and support you’ve provided. Bringing this feature to life was really a team effort—from the reviewers who meticulously went through hundreds of lines of code, to the backend developers like Piotr Skorupa (Backend Engineer, Plan:Knowledge at GitLab), who made this possible.” He expressed enthusiasm about collaborating with the team and “contributing to many more impactful features in the future!”

We are so grateful to Salihu for all of his contributions and to all of our open source community for contributing to GitLab!

17.9 Key improvements released in GitLab 17.9

Gitlab Duo Self-Hosted is generally available

Gitlab Duo Self-Hosted is generally available

You can now host selected large language models (LLMs) in your own infrastructure and configure those models as the source for GitLab Duo Code Suggestions and Chat. This feature is now generally available on self-managed GitLab environments with applicable licensing.

With GitLab Duo Self-Hosted, you can use models hosted either on-premise or in a private cloud as the source for GitLab Duo Chat or Code Suggestions. We currently support open-source Mistral models on vLLM or AWS Bedrock, Claude 3.5 Sonnet on AWS Bedrock, and OpenAI models on Azure OpenAI. By enabling self-hosted models, you can leverage the power of generative AI while maintaining complete data sovereignty and privacy.

Please leave feedback in issue 512753.

Gitlab Duo Self-Hosted is generally available

Run multiple Pages sites with parallel deployments

Run multiple Pages sites with parallel deployments

You can now create multiple versions of your GitLab Pages sites simultaneously with parallel deployments. Each deployment gets a unique URL based on your configured prefix. For example, with a unique domain your site would be accessible at project-123456.gitlab.io/prefix, or without a unique domain at namespace.gitlab.io/project/prefix.

This feature is especially helpful when you need to:

  • Preview design changes or content updates.
  • Test site changes in development.
  • Review changes from merge requests.
  • Maintain multiple site versions (for example, with localized content).

Parallel deployments expire after 24 hours by default to help manage storage space, though you can customize this duration or set deployments to never expire. For automatic cleanup, parallel deployments created from merge requests are deleted when the merge request is merged or closed.

Run multiple Pages sites with parallel deployments

Add project files to Duo Chat in VS Code and JetBrains IDEs

Add project files to Duo Chat in VS Code and JetBrains IDEs

Add your project files directly to Duo Chat in VS Code and JetBrains to unlock more powerful, context-aware AI assistance.

By adding project files, Duo Chat gains deep understanding of your specific codebase, enabling it to provide highly contextual and accurate responses. This context awareness gives you more relevant code explanations, precise debugging help, and suggestions that seamlessly integrate with your existing codebase. We welcome your feedback on this new, exciting feature. Please share your thoughts in our feedback issue.

Workspaces container support with Sysbox

Workspaces container support with Sysbox

GitLab workspaces now supports building and running containers directly in your development environment. When your workspace runs on a Kubernetes cluster configured with Sysbox, you can build and run containers without additional configuration.

Introduced in GitLab 17.4 as part of our sudo access feature, this capability enables you to maintain your complete container workflow in your GitLab workspace environment.

Create workspaces without a custom devfile

Create workspaces without a custom devfile

Previously, setting up a workspace required creating a devfile.yaml configuration file. GitLab now provides you with a default file that includes common development tools. This enhancement:

  • Removes configuration barriers.
  • Enables you to create a workspace quickly from any project.
  • Includes common development tools pre-configured and ready to use.
  • Lets you focus on development instead of configuration.

Start developing and create a workspace immediately without additional setup or configuration steps.

Create workspaces without a custom devfile

GitLab-managed Kubernetes resources

GitLab-managed Kubernetes resources

Deploy your applications to Kubernetes with more control and automation using GitLab-managed Kubernetes resources. Previously, you had to manually configure Kubernetes resources for each environment. Now, you can use GitLab-managed Kubernetes resources to automatically provision and manage these resources.

With GitLab-managed Kubernetes resources, you can:

  • Automatically create namespaces and service accounts for new environments
  • Manage access permissions through role bindings
  • Configure other required Kubernetes resources

When your developers deploy applications, GitLab automatically creates the necessary Kubernetes resources based on the provided resource templates, streamlining your deployment process and maintaining consistency across environments.

GitLab-managed Kubernetes resources

Simplified access to deployments within project environments

Simplified access to deployments within project environments

Have you ever struggled to get an overview of your deployments within a project? You can now view recent deployment details in the environments list without having to expand each environment. For each environment, the list shows your latest successful deployment and, if different, your most recent deployment attempt.

Simplified access to deployments within project environments

Wiki page comments

Wiki page comments

You can now add comments directly on wiki pages, transforming your documentation into an interactive collaboration space.

Comments and threads on wiki pages help teams:

  • Discuss content directly in context.
  • Suggest improvements and corrections.
  • Keep documentation accurate and up-to-date.
  • Share knowledge and expertise.

With wiki comments, teams can maintain living documentation that evolves alongside their projects through direct feedback and discussion.

Enhancing workflow visibility: new insights into merge request review time

Enhancing workflow visibility: new insights into merge request review time

To improve development workflow tracking, Value Stream Analytics (VSA) has been extended with a new event - Merge request last approved at. The merge request approval event marks the end of the review phase and the start of the final pipeline run or merge stage. For example, to calculate the total merge request review time, you can create a VSA stage with Merge request reviewer first assigned as the start event and Merge request last approved at as the end event.

With this enhancement, teams gain deeper insights into opportunities to optimize review times, which help reduce the overall cycle time of development, leading to faster software delivery.

Enhancing workflow visibility: new insights into merge request review time

EPSS, KEV, and CVSS data for vulnerability risk prioritization

EPSS, KEV, and CVSS data for vulnerability risk prioritization

We’ve added support for the following vulnerability risk data:

  • Exploit Prediction Scoring System (EPSS)
  • Known Exploited Vulnerabilities (KEV)
  • Common Vulnerabilities and Exposures (CVE)

You can now efficiently prioritize risk across your dependency and container image vulnerabilities using this data. You can find the data in the Vulnerability Report and in the Vulnerability Details page.

EPSS, KEV, and CVSS data for vulnerability risk prioritization

Configure DAST scans through the UI with full control

Configure DAST scans through the UI with full control

To effectively test complex applications, security teams need flexibility when they configure DAST scans. Previously, DAST scans configured through the UI had limited configuration options, which prevented successful scanning of applications with specific security requirements. This meant you had to use pipeline-based scans even for quick security assessments.

You can now configure DAST scans through the UI with the same granular control available in pipeline-based scans. This includes:

  • Full authentication configuration, including custom headers and cookies
  • Precise crawl settings like maximum pages, maximum depth, and excluded URLs
  • Advanced scan timeouts and retry attempts
  • Custom scanner behavior, like maximum links to crawl and DOM depth
  • Targeted scanning modes for specific vulnerability types

Save these configurations as reusable profiles to maintain consistent security testing across your applications. Every configuration change is tracked with audit events, so you know when scan settings are added, edited, or removed.

This enhanced control helps you run more effective security scans while maintaining compliance using detailed audit trails. Instead of spending time managing pipeline configurations, you can quickly launch the right scan for each application to find and fix vulnerabilities faster.

Configure DAST scans through the UI with full control

Automatic CI/CD pipeline cleanup

Automatic CI/CD pipeline cleanup

In the past, if you wanted to delete older CI/CD pipelines, you could only do this through the API.

In GitLab 17.9, we have introduced a project setting that allows you to set a CI/CD pipeline expiry time. Any pipelines and related artifacts older than the defined retention period are deleted. This can help reduce the disk usage in projects that run lots of pipelines that generate large artifacts, and even improve overall performance.

Automatic CI/CD pipeline cleanup

17.9 Other improvements in GitLab 17.9

Manage project integrations from a group with the REST API

Manage project integrations from a group with the REST API

Previously, you could manage project integrations from a group in the GitLab UI only. With this release, it’s possible to manage these integrations with the REST API too.

Thanks to Van for their initial community contribution, which was subsequently picked up and completed by GitLab.

Control access to GitLab Pages for groups

Control access to GitLab Pages for groups

You can now restrict GitLab Pages access at the group level. Group owners can enable a single setting to make all Pages sites in a group and its subgroups visible only to project members. This centralized control simplifies security management without modifying individual project settings.

Work items GraphQL API - additional query filters

Work items GraphQL API - additional query filters

The Work Items GraphQL API now includes additional query filters that let you filter by:

  • Created, updated, closed, and due dates
  • Health status
  • Weight

These new filters give you more control when querying and organizing work items through the API.

GitLab Runner 17.9

GitLab Runner 17.9

We’re also releasing GitLab Runner 17.9 today! GitLab Runner is the highly-scalable build agent that runs your CI/CD jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What’s new:

Bug Fixes:

The list of all changes is in the GitLab Runner CHANGELOG.

Get started with the GitLab integration with Kubernetes

Get started with the GitLab integration with Kubernetes

In this release, we added new Kubernetes Getting started guides that show you how to use GitLab to deploy applications to Kubernetes directly and with FluxCD. These easy-to-follow tutorials don’t require in-depth Kubernetes knowledge to complete, so both novice and experienced users can learn how to integrate GitLab and Kubernetes.

To supplement the Kubernetes Getting started guides, we also included a series of recommendations for integrating GitLab into Kubernetes environments.

Enable Dependency Scanning using SBOM for Cargo, Conda, Cocoapods and Swift projects

Enable Dependency Scanning using SBOM for Cargo, Conda, Cocoapods and Swift projects

In GitLab 17.9 the Composition Analysis team starts the transition to Dependency Scanning using SBOM with the new Dependency Scanning analyzer. This analyzer will be a replacement for Gemnasium, which will reach end of support in 18.0, remaining available for use through GitLab 19.0.

The Dependency Scanning using SBOM approach will better support customers through expansion of language support, a tighter integration and experience within the GitLab platform, and a shift towards industry standard report types (SBOM-based scanning and reporting). As of GitLab 17.9, the new Dependency Scanning analyzer will be enabled by default in the latest Dependency Scanning CI/CD template (Dependency-Scanning.latest.gitlab-ci.yml) for the following project and file types:

  • C/C++/Fortran/Go/Python/R projects using conda with a conda-lock.yml file.
  • Objective-C projects using Cocoapods with a podfile.lock file.
  • Rust projects using Cargo with a cargo.lock file.
  • Swift projects using Swift with a package.resolved file.

With this change we are introducing a new CI/CD variable: DS_ENFORCE_NEW_ANALYZER which is set to false by default.

This approach ensures that all existing customers of the latest template continue to use the Gemnasium analyzer by default and it enables automatically the new Dependency Scanning analyzer for the file types listed above.

Existing customers who wish to migrate to the new Dependency Scanning analyzer can set DS_ENFORCE_NEW_ANALYZER to true (at the project, group, or instance level). You can read more about this change in the deprecation announcement and the associated migration guide.

Customers who want to entirely prevent the use of the new Dependency Scanning analyzer must set the CI/CD variable DS_EXCLUDED_ANALYZERS to dependency-scanning.

Multi-core Advanced SAST offers faster scans

Multi-core Advanced SAST offers faster scans

GitLab Advanced SAST now offers multi-core scanning as an opt-in feature to improve performance. This can reduce scan duration significantly, especially for larger codebases.

To enable it, set the SAST_SCANNER_ALLOWED_CLI_OPTS CI/CD variable to --multi-core N, where N is the desired number of cores to use. You should only set this variable on the gitlab-advanced-sast job, not any other jobs. Check the documentation for important guidance on how to select the right value.

We’re working to enable this performance improvement by default; this is tracked in issue 517409.

Dependency list filter by component in projects

Dependency list filter by component in projects

On the Dependencies list in a project, you can now filter by the package name using the Component filter.

Previously, you could not search for packages in the Dependencies list for a project level. Now, setting the Component filter will find packages that contain the specified string.

Dependency list filter by component in projects

Filter by identifier in the project Vulnerability Report

Filter by identifier in the project Vulnerability Report

In the Vulnerability Report for a project, you can now filter the results by vulnerability identifier so you can find specific vulnerabilities (like CVEs or CWEs) that are in your project. You can use the identifier in conjunction with other filters like the severity, status, or tool filters. The vulnerability identifier filter is limited to reports with 20,000 vulnerabilities or less.

Filter by identifier in the project Vulnerability Report

Support merge request variables in pipeline execution policies

Support merge request variables in pipeline execution policies

Pipeline execution policies now support additional merge request variables, allowing you to create more sophisticated policies that take into account information related to the merge request. This provides more targeted and efficient control over CI/CD enforcement. The following variables are now supported:

  • CI_MERGE_REQUEST_SOURCE_BRANCH_SHA
  • CI_MERGE_REQUEST_TARGET_BRANCH_SHA
  • CI_MERGE_REQUEST_DIFF_BASE_SHA

With this enhancement, you can:

  • Implement advanced security scans that compare changes between source and target branches, ensuring thorough code review and vulnerability detection.
  • Create dynamic pipeline configurations that adapt based on the specifics of each merge request, streamlining your development process.

Custom expiration date for rotated service account tokens

Custom expiration date for rotated service account tokens

When rotating an access token for a service account, you can now use the expires_at attribute to set a custom expiration date. Previously, tokens automatically expired seven days after rotation. This allows for more granular management of token lifetimes, enhancing your ability to maintain secure access controls.

New permissions for custom roles

New permissions for custom roles

You can create custom roles with the Read compliance dashboard permission. Custom roles allow you to grant only the specific permissions users need to complete their tasks. This helps you define roles that are tailored to the needs of your group, and can reduce the number of users who need the Owner or Maintainer role.

Rotate access tokens with self_rotate scope

Rotate access tokens with self_rotate scope

You can now use the self_rotate scope to rotate access tokens. This scope is available for personal, project, or group access tokens. Previously, this required two requests: One to obtain a new token, then another to perform the token rotation.

Thank you Stéphane Talbot and Anthony Juckel for your contribution!

Support for additional group memberships with multiple OIDC providers

Support for additional group memberships with multiple OIDC providers

You can now configure additional group memberships when using multiple OIDC providers. Previously, if you configured multiple OIDC providers, you were limited to a single group membership.

View access token IP addresses

View access token IP addresses

Previously, when viewing your personal access tokens, the only usage information you could see was how many minutes ago the token was used. Now, you can also see up to the last seven IP addresses that the tokens were used from. This combined information can help you track where your token is being used.

Thank you Jayce Martin, Avinash Koganti, Austin Dixon, and Rohit Kala for your contribution!

View access token IP addresses

Composite identity for more secure AI connections

Composite identity for more secure AI connections

Previously, a request to GitLab could only be authenticated as a single user. With composite identity, we have now made it possible to authenticate a request as a service account and a user simultaneously. AI agent use cases often require permissions to be based on the user who initiated the tasks in a system, while simultaneously showing a distinct identity that’s separate from the initiating user. A composite identity is our new identity principal, which represents an AI agent’s identity. This identity is linked with the identity of the human user who requests actions from the agent. Whenever an AI agent action attempts to access a resource, a composite identity token is used. This token belongs to a service account, and is also linked with the human user who is instructing the agent. The authorization checks that run on the token take into account both principals before granting access to a resource. Both identities need to have access to the resource, otherwise access is denied. This new functionality enhances our ability to protect resources stored in GitLab. For more information about how the composite identity for service accounts can be used, see the documentation.

Change work item type to another

Change work item type to another

You can now easily change the type of your work items, giving you the flexibility to manage your projects more efficiently.

Change work item type to another

Speed up adding new child items by keeping the form open

Speed up adding new child items by keeping the form open

We’ve streamlined the process of creating multiple child items by keeping the form open after each submission, making it easier to add multiple entries without extra clicks. This update saves you time and ensures a smoother workflow when managing your tasks.

Workspace extensions now support proposed APIs

Workspace extensions now support proposed APIs

Workspace extensions now support enabling proposed APIs, improving compatibility and reliability in production environments. This update allows extensions that depend on proposed APIs to run without errors, including critical development tools like the Python Debugger. The change expands API access while maintaining stability.

Discover and migrate certificate-based Kubernetes clusters

Discover and migrate certificate-based Kubernetes clusters

The certificate-based Kubernetes integration will be turned off on GitLab.com for all users between May 6, 2025 9:00 AM UTC and May 8, 2025 22:00 PM UTC, and will be removed from GitLab Self-Managed instances in GitLab 19.0 (expected in May 2026).

To help users migrate, we added a new cluster API endpoint that group Owners can query to discover any certificate-based clusters registered to a group, subgroup, or project. We also updated the migration documentation to provide instructions for different types of use cases.

We encourage all GitLab.com users to check if they are affected, and to plan their migrations as soon as possible.

Implement OCI-based GitOps with the FluxCD CI/CD component

Implement OCI-based GitOps with the FluxCD CI/CD component

Have you ever wondered how to implement GitOps best practices with GitLab? The new FluxCD component makes it easy. Use the FluxCD component to package Kubernetes manifests into OCI images and store the images in OCI-compatible container registries. You can optionally sign the images and trigger an immediate FluxCD reconciliation.

License scanning support for Swift packages

License scanning support for Swift packages

In GitLab 17.9, we added support for license scanning on Swift packages. This will allow users who use Swift within their projects to better understand the licensing of their Swift packages.

This data is available to composition analysis users through the Dependency List, SBOM reports, and GraphQL API.

Block deletion of active security policy projects

Block deletion of active security policy projects

To ensure secure management of security policies and prevent disruption to enabled and enforced policies, we’ve added protection to prevent deletion of security policy projects that are in active use.

If a security policy project is linked to any groups or projects, the links must be removed before the security policy project can be deleted.

Enforce custom stages in pipeline execution policies

Enforce custom stages in pipeline execution policies

We’re excited to introduce a new capability for pipeline execution policies that allows you to enforce custom stages into your CI/CD pipelines in Inject mode. This feature provides greater flexibility and control over your pipeline structure while maintaining security and compliance requirements, supplying you with:

  • Enhanced pipeline customization: Define and inject custom stages at specific points in your pipeline, allowing for more granular control over job execution order.
  • Improved security and compliance: Ensure that security scans and compliance checks run at the most appropriate times in your pipeline, such as after build but before deployment.
  • Flexible policy management: Maintain centralized policy control while allowing development teams to customize their pipelines within defined guardrails.
  • Seamless integration: Custom stages work alongside existing project stages and other policy types, providing a non-disruptive way to enhance your CI/CD workflows.

How does it work?

The new and improved inject_policy strategy for pipeline execution policies allows you to define custom stages in your policy configuration. These stages are then intelligently merged with your project’s existing stages using a Directed Acyclic Graph (DAG) algorithm, ensuring proper ordering and preventing conflicts.

For example, you can now easily inject a custom security scanning stage between your build and deploy stages.

The inject_policy stage replaces inject_ci which will be deprecated, allowing you to opt into the inject_policy mode to gain the benefits. The inject_policy mode will become the default when configuring policies with Inject in the policy editor.

Enforce custom stages in pipeline execution policies

Support custom roles in merge request approval policies

Support custom roles in merge request approval policies

We’ve made merge request approval policies more flexible by adding the ability to assign custom roles as approvers.

You can now tailor approval requirements to match your organization’s unique team structures and responsibilities, ensuring the right roles are engaged in the review process based on the policy. For example, require approval from AppSec Engineering roles for security reviews and Compliance roles for license approvals.

Support custom roles in merge request approval policies

Apply a compliance framework by using a project’s compliance center

Apply a compliance framework by using a project’s compliance center

In GitLab 17.2, we released the ability for group owners to apply and remove compliance frameworks for all projects in a group by using the group’s compliance center.

We have expanded this to now allow group owners to also apply and remove compliance frameworks at the project level. This will make it even easier for group owners to apply and monitor compliance frameworks at the project level.

The ability to apply and remove compliance frameworks at the project level is only available for group owners and not project owners.

Email notifications for service accounts

Email notifications for service accounts

You can now set a custom email address to receive email notifications for service accounts. When a custom email address is specified when creating a service account, GitLab sends notifications to that address. Each service account must use a unique email address. This can help you monitor processes and events more effectively.

Thank you Gilles Dehaudt, Étienne Girondel, Kevin Caborderie, Geoffrey McQuat, Raphaël Bihore from the SNCF Connect & Tech team for your contribution!

OAuth application authorization audit event

OAuth application authorization audit event

Previously, when a user authorized an OAuth application, no audit event was generated. However, this event is important for security teams to monitor the OAuth applications authorized by users on a specific GitLab instance.

With this release, GitLab now provides a User authorized an OAuth application audit event to track when users successfully authorize OAuth applications. This new audit event further improves your ability to audit your GitLab instance.

Search and filter the Credentials Inventory

Search and filter the Credentials Inventory

You can now use search and filter capabilities in the Credentials Inventory. This makes it easier to identify tokens and keys which fall within certain user-defined parameters, including tokens that expire within a certain window. Previously, the entries in the Credentials Inventory were presented as a static list.

Search and filter the Credentials Inventory

Use API to disable 2FA for individual enterprise users

Use API to disable 2FA for individual enterprise users

You can now use the API to clear all two-factor authentication (2FA) registrations for an individual enterprise user. Previously, this was only possible in the UI. Using the API allows for automated and bulk operations, saving time when 2FA resets need to be done at scale.

View inactive project and group access tokens

View inactive project and group access tokens

You can now view inactive group and project access tokens in the UI. Previously, GitLab instantly deleted project and group access tokens after they expired or were revoked. This lack of a record of inactive tokens made auditing and security reviews more difficult. GitLab now retains inactive group and project access token records for 30 days, which helps teams track token usage and expiration for compliance and monitoring purposes.

View inactive project and group access tokens

Group sharing visibility enhancement

Group sharing visibility enhancement

We’re excited to announce expanded visibility for group sharing across GitLab. Previously, while you could see shared projects on a group’s overview page, you couldn’t see which groups your group had been invited to join. Now you can view both Shared projects and Shared groups tabs on the group overview page, giving you a complete view of how your groups are connected and shared throughout your organization. This makes it easier to audit and manage group access across your organization.

We welcome feedback about this change in epic 16777.

Group sharing visibility enhancement

Restrict users from making their profile private

Restrict users from making their profile private

Users can choose to make their user profile public or private. Administrators can now control whether users have the option to make profiles private across their GitLab instance. In the Admin Area, “Allow users to make their profiles private” controls this setting. This setting is enabled by default, allowing users to choose private profiles.

Features in Experiment Features in Experiment

Fine-grained permissions for job tokens

Fine-grained permissions for job tokens

Job tokens are ephemeral credentials that provide access to resources in pipelines. Since these tokens inherit permissions from the user, they often have broad access capabilities. Fine-grained permissions for job tokens allow you to control which resources a job token can access in a project.

We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team, see this feedback issue.

Bug fixes, performance improvements, and UI improvements

Bug fixes, performance improvements, and UI improvements

At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance UI. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.

Click the links below to see all the bug fixes, performance enhancements, and UI improvements we’ve delivered in 17.9.

Deprecations Deprecations

New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

  • Reject container image pull policies not in `allowed_pull_policies`
  • Updating CI/CD job tokens to JWT standard
  • Default GitLab Runner's `FF_GIT_URLS_WITHOUT_TOKENS` feature flag to `true`
  • New data retention limits for vulnerabilities on GitLab.com
  • End-of-Support SAST jobs will be removed from the CI/CD template
  • Application Security Testing analyzers major version update
  • Linux packages for Ubuntu 20.04
  • Make the `gitlab-runner-helper-images` Linux OS package an optional dependency of `gitlab-runner`
  • Remove duoProAssignedUsersCount GraphQL field
  • SAST jobs no longer use global cache settings
  • Major update of the Prometheus subchart
  • REST API endpoint `pre_receive_secret_detection_enabled` is deprecated
  • The `agentk` container registry is moving to Cloud Native GitLab
  • `kpt`-based `agentk` is deprecated
  • GitLab Advanced SAST will be enabled by default
  • Legacy Web IDE is deprecated
  • `defaultMaxHoursBeforeTermination` and `maxHoursBeforeTerminationLimit` fields are deprecated
  • `maxHoursBeforeTermination` GraphQL field is deprecated
  • `RemoteDevelopmentAgentConfig` GraphQL type is deprecated
  • Legacy Geo Prometheus repository checks metrics
  • Subscription related API endpoints in the public API are deprecated
  • Support for SUSE Linux Enterprise Server 15 SP2
  • Container Scanning default severity threshold set to `medium`
  • API Discovery will use branch pipelines by default
  • Dependency Proxy token scope enforcement
  • DAST `dast_devtools_api_timeout` will have a lower default value
  • Resolve a vulnerability for Dependency Scanning on Yarn projects
  • Dependency Scanning upgrades to the GitLab SBOM Vulnerability Scanner
  • Dependency Scanning for JavaScript vendored libraries
  • Raspberry Pi 32-bit packages are deprecated
  • Removals and breaking changes Removals and breaking changes

    The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

    • Support for openSUSE Leap 15.5
    • Changelog Changelog

      Please check out the changelog to see all the named changes:

      Installing Installing

      If you are setting up a new GitLab installation please see the download GitLab page.

      Updating Updating

      Check out our update page.

      Questions? Questions?

      We'd love to hear your thoughts! Visit the GitLab Forum and let us know if you have questions about the release.

      GitLab Subscription Plans GitLab Subscription Plans

      • Free

        Free-forever features for individual users

      • Premium

        Enhance team productivity and coordination

      • Ultimate

        Organization wide security, compliance, and planning

      Try all GitLab features - free for 30 days

      We want to hear from you

      Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

      Share your feedback

      Take GitLab for a spin

      See what your team could do with The DevSecOps Platform.

      Get free trial

      Have a question? We're here to help.

      Talk to an expert
      Edit this page View source