GitLab 17.0 Release

GitLab 17.0 released with generally available CI/CD Catalog and AI Impact analytics dashboard

GitLab 17.0 released with generally available CI/CD Catalog, AI Impact analytics dashboard, hosted runners on Linux Arm, deployment detail pages, and much more!

Today, we are excited to announce the release of GitLab 17.0 with generally available CI/CD Catalog, AI Impact analytics dashboard, hosted runners on Linux Arm, deployment detail pages, and much more!

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

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

Join us to explore the new AI-powered features in GitLab 17 that will help you improve collaboration, visibility, security, and cycle times. Register for the GitLab 17 release virtual event: The future of AI-driven software development.

To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 17.1 release kickoff video.

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is jointly awarded to Niklas van Schrick and Gerardo Navarro

Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination 🙌

Niklas van Schrick now has the hat trick with three MVPs and has become one of GitLab’s most consistent contributors with at least one merge request per milestone since GitLab 14.3.

Niklas was nominated by Magdalena Frankiewicz, Product Manager at GitLab, for contributing a feature to create custom webhook payload templates and then following it up with the ability to specify custom webhook headers. “This solved a highly demanded 7-year-old feature request with 65 upvotes,” says Magdalena. “Users can now fully design custom webhooks!”

Niklas is a member of the GitLab Core Team and helps the wider community and GitLab live up to our mission to enable everyone to contribute.

“During my journey, I interacted with a lot of different reviewers, maintainers, designers, technical writers, product managers, and probably more,” Niklas says. “Everyone was helpful and did their best to help move issues and merge requests forward.”

Gerardo Navarro has been contributing to GitLab for over a year and takes home a second GitLab MVP award.

Gerardo was nominated for creating ongoing contributions towards a feature to show protected packages in the package registry list. This feature is part of a series of contributions related to the protected packages epic that intends to increase security by enabling fine-grained permissions to create, update, and delete packages from the package registry.

Many thanks to Gerardo Navarro and the rest of the team from Siemens for helping co-create GitLab.

“Thank you very much for appreciating our work with such a cool award,” says Gerardo. “I feel honored. I am still learning a lot with every contribution.”

17.0 Key improvements released in GitLab 17.0

CI/CD Catalog with components and inputs now generally available

CI/CD Catalog with components and inputs now generally available

The CI/CD Catalog is now generally available. As part of this release, we’re also making CI/CD components and inputs generally available.

With the CI/CD Catalog, you gain access to a vast array of components created by the community and industry experts. Whether you’re seeking solutions for continuous integration, deployment pipelines, or automation tasks, you’ll find a diverse selection of components tailored to suit your requirements. You can read more about the Catalog and its features in the following blog post.

You’re invited to contribute CI/CD components to the Catalog and help expand this new and growing part of GitLab.com!

AI Impact analytics in the Value Streams Dashboard

AI Impact analytics in the Value Streams Dashboard

AI Impact is a dashboard available in the Value Streams Dashboard that helps organizations understand the impact of GitLab Duo on their productivity. This new month-over-month metric view compares the AI Usage trends with SDLC metrics like lead time, cycle time, DORA, and vulnerabilities. Software leaders can use the AI Impact dashboard to measure how much time is saved in their end-to-end workstream, while staying focused on business outcomes rather than developer activity.

In this first release, the AI usage is measured as the monthly Code Suggestions usage rate, and is calculated as the number of monthly unique Code Suggestions users divided by total monthly unique contributors.

The AI Impact dashboard is available to users on the Ultimate tier for a limited time. Afterwards, a GitLab Duo Enterprise license will be required to use the dashboard.

AI Impact analytics in the Value Streams Dashboard

Introducing hosted runners on Linux Arm

Introducing hosted runners on Linux Arm

We are excited to introduce hosted runners on Linux Arm for GitLab.com. The now available medium and large Arm machine types, equipped with 4 and 8 vCPUs respectively, and fully integrated with GitLab CI/CD, will allow you to build and test your application faster and more cost-efficient than ever before.

We are determined to provide the industry’s fastest CI/CD build speed and look forward to seeing teams achieve even shorter feedback cycles and ultimately deliver software faster.

Introducing hosted runners on Linux Arm

Introducing deployment detail pages

Introducing deployment detail pages

You can now link directly to a deployment in GitLab. Previously, if you were collaborating on a deployment, you had to look up the deployment from the deployment list. Because of the number of deployments listed, finding the correct deployment was difficult and prone to error.

From 17.0, GitLab offers a deployment details view that you can link to directly. In this first version, the deployment details page offers an overview of the deployment job and the possibility to approve, reject, or comment on a deployment in a continuous delivery setting. We are looking into further avenues to enhance the deployment details page, including by linking to it from the related pipeline job. We would love to hear your feedback in issue 450700.

Introducing deployment detail pages

GitLab Duo Chat now uses Anthropic Claude 3 Sonnet

GitLab Duo Chat now uses Anthropic Claude 3 Sonnet

GitLab Duo Chat just got a lot better. It now uses Anthropic Claude 3 Sonnet as the base model, replacing Claude 2.1 for answering most questions.

At GitLab, we apply a test-driven approach when choosing the best model for a set of tasks and authoring well-performing prompts. With recent adjustments to the chat prompts, we have achieved significant improvements in the correctness, comprehensiveness, and readability of chat answers based on Claude 3 Sonnet compared to the previous chat version built on Claude 2.1. Hence, we have now switched to this new model version.

GitLab Duo Chat now uses Anthropic Claude 3 Sonnet

How-to questions in GitLab Duo Chat supported on self-managed deployments

How-to questions in GitLab Duo Chat supported on self-managed deployments

A popular capability of GitLab Duo Chat is answering questions about how to use GitLab. While Chat offers various other capabilities, this particular functionality was previously only available on GitLab.com. With this release, we’re making it accessible to GitLab self-managed deployments as well, aligning with our commitment to delivering a delightful experience across all types of deployments.

Whether you’re a newcomer or an expert, you can ask Chat for help with queries like “How do I change my password in GitLab?” or “How do I connect a Kubernetes cluster to GitLab?”. Chat aims to provide helpful information to solve your problems more efficiently.

How-to questions in GitLab Duo Chat supported on self-managed deployments

New usage overview panel in the Value Streams Dashboard

New usage overview panel in the Value Streams Dashboard

We enhanced the Value Streams Dashboard with an Overview panel. This new visualization addresses the need for executive-level insights into software delivery performance, and gives a clear picture of GitLab usage in the context of software development life cycle (SDLC).

The Overview panel displays metrics for the group level, such as number of (sub)groups, projects, users, issues, merge requests, and pipelines.

New usage overview panel in the Value Streams Dashboard

Add a group to the CI/CD job token allowlist

Add a group to the CI/CD job token allowlist

Introduced in GitLab 15.9, the CI/CD job token allowlist prevents unauthorized access from other projects to your project. Previously, you could allow access at the project level from other specific projects only, with a maximum limit of 200 total projects.

In GitLab 17.0, you can now add groups to a project’s CI/CD job token allowlist. The maximum limit of 200 now applies to both projects and groups, meaning a project allowlist can now have up to 200 projects and groups authorized for access. This improvement makes it easier to add large numbers of projects associated with a group.

Add a group to the CI/CD job token allowlist

Enhanced context control with the rules:exists CI/CD keyword

Enhanced context control with the rules:exists CI/CD keyword

The rules:exists CI/CD keyword has default behaviors that vary based on where the keyword is defined, which can make it harder to use with more complex pipelines. When defined in a job, rules:exists searches for specified files in the project running the pipeline. However, when defined in an include section, rules:exists searches for specified files in the project hosting the configuration file containing the include section. If configuration is split over multiple files and projects, it can be hard to know which exact project will be searched for defined files.

In this release, we have introduced project and ref subkeys to rules:exists, providing you a way to explicitly control the search context for this keyword. These new subkeys help you ensure accurate rule evaluation by precisely specifying the search context, mitigating inconsistencies, and enhancing clarity in your pipeline rule definitions.

Enhanced context control with the `rules:exists` CI/CD keyword

Change log for configuration changes made using Switchboard

Change log for configuration changes made using Switchboard

You can now view the status of configuration changes made to your GitLab Dedicated instance infrastructure using the Switchboard configuration page.

All users with access to view or edit your tenant in Switchboard will be able to view changes in the Configuration Change log and track their progress as they are applied to your instance.

Currently, the Switchboard configuration page and change log are available for changes like managing access to your instance by adding an IP to the allowlist or configuring your instance’s SAML settings.

We will be extending this functionality to enable self-serve updates for additional configurations in coming quarters.

Change log for configuration changes made using Switchboard

17.0 Other improvements in GitLab 17.0

Enable viewing Jira issues in GitLab with the REST API

Enable viewing Jira issues in GitLab with the REST API

With this release, you can use the REST API to enable viewing Jira issues in GitLab. You can also specify one or more Jira projects to view issues from.

Thanks to Ivan for this community contribution!

Indicate that items were imported using direct transfer

Indicate that items were imported using direct transfer

You can migrate GitLab groups and projects between GitLab instances by using direct transfer.

Until now, imported items were not easily identifiable. With this release, we’ve added visual indicators to items imported with direct transfer, where the creator is identified as a specific user:

  • Notes (system notes and user comments)
  • Issues
  • Merge requests
  • Epics
  • Designs
  • Snippets
  • User profile activity

View issues from multiple Jira projects in GitLab

View issues from multiple Jira projects in GitLab

For larger repositories, you can now view issues from multiple Jira projects in GitLab when you set up the Jira issue integration. With this release, you can:

  • Enter up to 100 Jira project keys separated by commas.
  • Leave Jira project keys blank to include all available keys.

When you view Jira issues in GitLab, you can filter the issues by project.

To create Jira issues for vulnerabilities in GitLab Ultimate, you can specify only one Jira project.

Enhanced epic deletion protection

Enhanced epic deletion protection

We’ve updated what happens when you delete an epic to better safeguard your project’s structure and data. It’s all about giving you more control and peace of mind while managing your projects.

Now, when you delete a parent epic, instead of deleting all its child records automatically, we preserve them by detaching the parent relationship first. This change provides you with a safer way to manage your epics, ensuring accidental deletions don’t result in losing valuable information.

Milestones and iterations visible on issue boards

Milestones and iterations visible on issue boards

We’ve improved issue boards to offer you clearer insights into your project’s timeline and phases. Now, with milestone and iteration details directly visible on issue cards, you can easily track progress and adjust your team’s workload on the fly. This enhancement is designed to make your planning and execution more efficient, keeping you in the loop and ahead of schedule.

Milestones and iterations visible on issue boards

Simplified configuration file schema for Value Streams Dashboard

Simplified configuration file schema for Value Streams Dashboard

You can now customize Value Streams Dashboard panels using a simplified schema-driven customizable UI framework. In the new format, the fields provide more flexibility of displaying the data and laying out the dashboard panels. With the new framework, administrators can track changes to the dashboard over time. This version history can help you revert to previous versions and compare changes between dashboard versions.

Using this customization, decision-makers can focus on the most relevant information for their business, while teams can better organize and display key DevSecOps metrics.

1Password secrets integration in GitLab Duo Plugin for JetBrains IDEs

1Password secrets integration in GitLab Duo Plugin for JetBrains IDEs

You can now integrate 1Password secrets management with the GitLab Duo plugin for JetBrains.

Developers can replace their personal access tokens in their JetBrains IDE settings with 1Password secrets references. This simplifies managing secrets, and enables seamless secrets rotation without manual token updates.

1Password secrets integration in GitLab Duo Plugin for JetBrains IDEs

Commit signing for GitLab UI commits

Commit signing for GitLab UI commits

Previously, web commits and automated commits made by GitLab could not be signed. Now you can configure your self-managed instance with a signing key, a committer name, and email address to sign web and automated commits.

Commit signing for GitLab UI commits

Always run after_script commands for canceled jobs

Always run after_script commands for canceled jobs

The after_script CI/CD keyword is used to run additional commands after the main script section of a job. This is often used for cleaning up environments or other resources that were used by the job. However, after_script commands did not run if a job was canceled.

As of GitLab 17.0, after_script commands will always run when a job is canceled. To opt out, see the documentation.

Semantic version ranges for published CI/CD components

Semantic version ranges for published CI/CD components

When using a CI/CD Catalog component, you might want to have it automatically use the latest version. For example, you don’t want to have to manually monitor all the components you use and manually switch to the next version every time there is a minor update or security patch. But using ~latest is also a bit risky because minor version updates could have undesired behavior changes, and major version updates have a higher risk of breaking changes.

With this release, you can opt to use the latest major or minor version of a CI/CD component. For example, specify 2 for the component version, and you’ll get all updates for that major version, like 2.1.1, 2.1.2, 2.2.0, but not 3.0.0. Specify 2.1 and you’ll only get patch updates for that minor version, like 2.1.1, 2.1.2, but not 2.2.0.

Filter package registry UI for packages with errors

Filter package registry UI for packages with errors

You can use the GitLab package registry to publish and download packages. Sometimes, packages fail to upload due to an error. Previously, there was no way to quickly view packages that failed to upload. This made it challenging to get a holistic view of your organization’s package registry.

Now you can filter the package registry UI for packages that failed to upload. This improvement makes it easier to investigate and resolve any issues you encounter.

Support for GitLab agent for Kubernetes in FIPS mode

Support for GitLab agent for Kubernetes in FIPS mode

From GitLab 17.0, you can install GitLab in FIPS mode with the agent for Kubernetes components enabled. Now, FIPS-compliant users can benefit from all the Kubernetes integrations with GitLab.

Multiple external participants for Service Desk

Multiple external participants for Service Desk

Sometimes there is more than one person involved in resolving a support ticket or the requester wants to keep colleagues up-to date on the state of the ticket.

Now you can have a maximum of 10 external participants without a GitLab account on a Service Desk ticket and regular issues.

External participants receive Service Desk notification emails for each public comment on the ticket, and their replies will appear as comments in the GitLab UI.

Simply use the quick actions /add_email and remove_email to add or remove external participants with a few keystrokes.

You can also configure GitLab to add all email addresses from the Cc header of the initial email to the Service Desk ticket.

You can tailor all Service Desk email templates to your liking, using markdown, HTML, and dynamic placeholders. An unsubscribe link placeholder is available to make it easy for external participants to opt out of a conversation.

DAST now supports both arm64 and amd64 architectures by default

DAST now supports both arm64 and amd64 architectures by default

DAST 5 supports both arm64 and amd64 architectures by default. This enables customers to choose the Runner host architecture and optimize cost savings.

Dependency Scanning support for Android

Dependency Scanning support for Android

Users of Dependency Scanning can now scan Android projects. To configure Android scanning, use the CI/CD Catalog component. Android scanning is also supported for users of the CI/CD template.

Secret Detection now supports remote rulesets when overriding or disabling rules

Secret Detection now supports remote rulesets when overriding or disabling rules

We resolved a Secret Detection bug that impacted remote rulesets. It’s now possible to override or disable rules via remote rulesets. Remote rulesets offer a scalable way to configure rules in a single place, which can be applied across multiple projects.

Automatic deletion of unverified secondary email addresses

Automatic deletion of unverified secondary email addresses

If you add a secondary email address to your user profile and do not verify it, that email address is now automatically deleted after three days. Previously, these email addresses were in a reserved state and could not be released without manual intervention. This automatic deletion reduces administrator overhead and prevents users from reserving email addresses that they do not have ownership of.

Edit a custom role and its permissions

Edit a custom role and its permissions

Previously, you could not edit an existing custom role and its permissions. Now, you can edit a custom role and its permissions without having to re-create the role to make a change.

Improved branch protection settings for administrators and for groups.

Improved branch protection settings for administrators and for groups.

Previously, setting up default branch protection options did not allow for the same level of configuration that the settings for protected branches did.

In this release, we have updated the default branch protection settings to provide the same experience that you have with protected branches. This allows more flexibility in protecting your default branch and simplifies the process to match what already exists in the protected branch settings.

New permissions for custom roles

New permissions for custom roles

There are new permissions available you can use to create custom roles:

With the release of these custom permissions, you can reduce the number of Owners needed in a group by creating a custom role with these Owner-equivalent permissions. Custom roles allow you to define granular roles that give a user only the permissions they need to do their jobs, and reduce unnecessary privilege escalation.

Toggle merge request approval policies to fail open or fail closed

Toggle merge request approval policies to fail open or fail closed

Compliance operates on a sliding scale for many organizations as they strike a balance between meeting requirements and ensuring developer velocity is not impacted. Merge request approval policies help to operationalize security and compliance in the heart of the DevSecOps workflow - the merge request. We’re introducing a new fail open option for merge request approval policies to offer flexibility to teams who want to ease the transition to policy enforcement as they roll out controls in their organization.

When a merge request approval policy is configured to fail open, MRs will now only be blocked if a policy rule is violated and if that project has the security analyzer properly configured. If an analyzer is not enabled for a project or if the analyzer does not successfully produce results, the policy will no longer consider this a violation for the given rule and analyzer. This approach allows for progressive rollout of policies as teams work to ensure proper scan execution and enforcement.

Toggle merge request approval policies to fail open or fail closed

Updated filtering on the Vulnerability Report

Updated filtering on the Vulnerability Report

The old implementation of the Vulnerability Report filters wasn’t scalable. We were limited by horizontal space on the page. You can now use the filtered search component to filter the Vulnerability Report by any combination of status, severity, tool, or activity. This change allows us to add new filters, like this proposed filter by identifier.

Updated filtering on the Vulnerability Report

Linux package improvements

Linux package improvements

CentOS Linux 7 will reach end of life on June 30, 2024. This makes GitLab 17.1 the last GitLab version in which we can provide packages for CentOS 7.

Private shared group members are listed on Members tab for all members

Private shared group members are listed on Members tab for all members

Previously, when a public group or project invited a private group, the private group was listed only in the Groups tab of the Members page, and private members were not visible to members of the public group. To enable better collaboration between members of these groups, we are now also listing all invited group members in the Members tab, including members from private invited groups. The source of membership will be masked from members that do not have access to the private group. However, the source of membership will be visible to users who have at least the Maintainer role in the project or Owner role in the group, so that they can manage members in their project or group. If the current user viewing the Members tab is unauthenticated or not a member of the group or project, they will not see the private group members. We hope this change will make it easier for group and project members to understand at a glance who has access to a group or project.

Import from Bitbucket Cloud by using REST API

Import from Bitbucket Cloud by using REST API

In this milestone, we added the ability to import Bitbucket Cloud projects by using the REST API.

This can be a better solution for importing a lot of projects than importing by using the UI.

Re-import a chosen project relation by using the API

Re-import a chosen project relation by using the API

When importing projects from export files with many items of the same type (for example, merge requests or pipelines), sometimes some of those items weren’t imported.

In this release, we added an API endpoint that re-imports a named relation, skipping items that have already been imported. The API requires both:

  • A project export archive.
  • A type (issues, merge requests, pipelines, or milestones).

Design Management features extended to Product teams

Design Management features extended to Product teams

GitLab is expanding collaboration by updating our permissions. Now, users with the Reporter role can access Design Management features, enabling product teams to engage more directly in the design process. This change simplifies workflows and accelerates innovation by inviting broader participation from across your organization.

We reduced the minimum role required to relate issues and tasks from Reporter to Guest, giving you more flexibility to organize work across your GitLab instance while maintaining permissions.

New median time to merge metric in Value Streams Dashboard

New median time to merge metric in Value Streams Dashboard

We added a new metric to the Value Streams Dashboard: median time to merge. In GitLab, this metric represents the median time between when a merge request was created and when it was merged. This new metric measures DevOps health by identifying the efficiency and productivity of your merge request and code review processes.

By analyzing how this metric evolves in the context of other SDLC metrics, teams can identify low or high productivity months, understand the impact of new DevOps practices on the development speed and delivery process, reduce their overall lead time, and increase the velocity of their software delivery.

New median time to merge metric in Value Streams Dashboard

Sort the Roadmap by created date, last updated date, and title

Sort the Roadmap by created date, last updated date, and title

We expanded the epic sorting options available in the Roadmap view, providing you more flexibility in organizing and prioritizing your projects. You can now sort epics by created date, last updated date, and title. This enhancement lays the groundwork for even more advanced sorting capabilities in the future to help you manage epics more dynamically.

Sort the Roadmap by created date, last updated date, and title

Access GitLab Duo Chat faster with customizable shortcuts

Access GitLab Duo Chat faster with customizable shortcuts

Opening Duo Chat directly from your editor in JetBrains is now even easier.

Use the default Alt+D keyboard shortcut (or set your own) to open Duo Chat quickly and type your question. Use the same keyboard shortcut to close the window.

Access GitLab Duo Chat faster with customizable shortcuts

Project comment templates

Project comment templates

Following the release of group comment templates in GitLab 16.11, we’re bringing these to projects in GitLab 17.0.

Across an organization, it can be helpful to have the same templated response in issues, epics, and merge requests. These responses might include standard questions that need to be answered, responses to common problems, or good structure for merge request review comments. Project-level comment templates give you an additional way to scope the availability of templates, bringing organizations more control and flexibility in sharing these across users.

To create a comment template, go to any comment box on GitLab and select Insert comment template > Manage project comment templates. After you create a comment template, it’s available for all project members. Select the Insert comment template icon while making a comment, and your saved response will be applied.

We’re really excited about this iteration of comment templates and if you have any feedback, please leave it in issue 45120.

Project comment templates

GitLab Runner 17.0

GitLab Runner 17.0

We’re also releasing GitLab Runner 17.0 today! GitLab Runner is the lightweight, highly-scalable 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:

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

Standardized CI/CD Catalog component publishing process

Standardized CI/CD Catalog component publishing process

We have been hard at work on CI/CD components, including making the process of releasing components to the CI/CD Catalog a consistent experience. As part of that work, we’ve made releasing versions from a CI/CD job with the release keyword and the release-cli image the only method. All improvements to the release process will apply to this method only. To avoid breaking changes introduced by this restriction, make sure you always use the latest version of the image (release-cli:latest) or at least a version greater than v0.17. The Releases option in the UI is now disabled for CI/CD component projects.

Increase Kubernetes agent authorization limit

Increase Kubernetes agent authorization limit

With the GitLab agent for Kubernetes, you can share a single agent connection with a group. We aim to support a single agent across a large multi-tenant cluster. However, you might have faced a limitation on the number of connection sharing. Until now, an agent could be shared with only 100 projects and groups using CI/CD, and 100 projects and groups using the user_access keyword. In GitLab 17.0, the number of projects and groups you can share with is raised to 500.

If you need to run multiple agents in a cluster, we would like to hear your feedback in issue 454110.

Track fast-forward merge requests in deployments

Track fast-forward merge requests in deployments

In past releases, merge requests were tracked in a deployment only if the project’s merge method was Merge commit or Merge commit with semi-linear history. From GitLab 17.0, merge requests are tracked in deployments, including in projects with the merge method Fast-forward merge.

API Security Testing analyzer updates

API Security Testing analyzer updates

We published the following API Security Testing analyzer updates during the 17.0 release milestone: - System environment variables are now passed from the CI runner to the custom Python scripts used for certain advanced scenarios (like request signing). This will make implementing these scenarios easier. See issue 457795 for more details. - API Security containers now run as a non-root user, which improves flexibility and compliance. See issue 287702 for more details. - Support for servers that only offer TLSv1.3 ciphers, which enables more customers to adopt API Security Testing. See issue 441470 for more details. - Upgrade to Alpine 3.19, which addresses security vulnerabilities. See issue 456572 for more details.

As previously announced, we increased the major version number of API Security Testing to version 5 in GitLab 17.0.

Dependency Scanning default Python image

Dependency Scanning default Python image

Following the deprecation of Python 3.9 as the default Python image, Python 3.11 is now the default image.

As outlined in the deprecation notice, the target for the new default Python version was 3.10. The direct move to Python 3.11 was required to ensure FIPS compliance.

Introducing advanced vulnerability tracking for Secret Detection

Introducing advanced vulnerability tracking for Secret Detection

Secret Detection now uses an advanced vulnerability tracking algorithm to more accurately identify when the same secret has moved within a file due to refactoring or unrelated changes. A new finding is no longer created if:

  • A leak moves within a file.
  • A new leak of the same value appears within the same file.

Otherwise, the existing workflow (merge request widget, pipeline report, and vulnerability report) will treat the findings the same as before. By ensuring that duplicate vulnerabilities are not reported as secrets shift locations, teams are more easily able to manage leaked secrets.

Streamlined SAST analyzer coverage for more languages

Streamlined SAST analyzer coverage for more languages

GitLab Static Application Security Testing (SAST) now scans the same languages with fewer analyzers, offering a simpler, more customizable scan experience.

In GitLab 17.0, we’ve replaced language-specific analyzers with GitLab-managed rules in the Semgrep-based analyzer for the following languages:

  • Android
  • C and C++
  • iOS
  • Kotlin
  • Node.js
  • PHP
  • Ruby

As announced, we’ve updated the SAST CI/CD template to reflect the new scanning coverage and to remove language-specific analyzer jobs that are no longer used.

Customize avatars for users

Customize avatars for users

You can now use the API to upload a custom avatar for any user type, including bot users. This can be especially helpful for visually distinguishing bot users, such as group and project access tokens or service accounts, from human users in the UI. Thank you Phawin for your contribution!

Identify sessions initiated by Admin Mode

Identify sessions initiated by Admin Mode

As an instance administrator, when you use multiple browsers or different computers, it is difficult to know which sessions are in Admin Mode and which aren’t. Now, administrators can go to User Settings > Active Sessions to identify which sessions use Admin Mode.

Thank you Roger Meier for your contribution!

Identify sessions initiated by Admin Mode

Manage custom roles at self-managed instance level

Manage custom roles at self-managed instance level

Before this release, on self-managed GitLab, custom roles had to be created at the group level. This meant administrators could not centrally manage custom roles for the instance, which resulted in duplicate roles across the instance. Now custom roles are managed at the self-managed instance level. Only administrators can create custom roles, but both administrators and group Owners can assign these custom roles.

For more information on migrating existing custom roles, API endpoints, and workflows, see epic 11851.

This update does not impact custom role workflows on GitLab.com.

Optional configuration for policy bot comment

Optional configuration for policy bot comment

The security policy bot posts a comment on merge requests when they violate a policy to help users understand when policies are enforced on their project, when evaluation is completed, and if there are any violations blocking an MR, with guidance to resolve them. These comments are now optional and can be enabled or disabled within each policy. This gives organizations the flexibility and control to determine how they want to communicate about these policies to their users.

Optional configuration for policy bot comment

GitLab chart improvements

GitLab chart improvements

The GitLab Operator is now available for production use for cloud-native hybrid installations. See the installation documentation before adopting the GitLab Operator.

Support for a fallback to BusyBox images when you specify custom BusyBox values (global.busybox) is removed. Support for BusyBox-based init containers was deprecated in GitLab 16.2 (Helm chart 7.2) in favor of a common GitLab-based init image.

Support for gitlab.kas.privateApi.tls.enabled and gitlab.kas.privateApi.tls.secretName is also removed. You must use global.kas.tls.enabled and global.kas.tls.secretName instead.

The deprecated queue selector and negate options are removed from the Sidekiq chart.

Members page displays members from invited groups

Members page displays members from invited groups

Previously, members of groups that were invited to a group or project were visible only in the Groups tab of the Members page. This meant users had to check both the Groups and Members tabs to understand who has access to a certain group or project. Now, shared members are listed also in the Members tab, giving a complete overview of all the members that are part of a group or project at a glance.

Two database mode is available in Beta

Two database mode is available in Beta

Currently, most self-managed customers only utilize a single database. In order to ensure that the setup between GitLab.com and self-managed is the same, we ask self-managed customers to migrate and run decomposed by default. In 16.0, two database connections became the default for self-managed installations. In 17.0, we will end support for single database connections on self-managed, but we will continue supporting single databases with two connections until 19.0. In 17.0, we release two database mode as a limited Beta, with the goal to make running decomposed generally available by 19.0. Migration remains optional in 17.0, but needs to be performed before upgrading to 19.0.

The migration requires downtime. Self-managed customers can use a tool that executes this migration with some downtime. We introduced a new gitlab-ctl command that allows you to upgrade your single-database GitLab instances to a decomposed setup. This setup contains commands that will work with our Linux package. The actual migration (copying the database) is part of a rake task in the GitLab project.

Features in Experiment Features in Experiment

Get even more Code Suggestions with customizable language settings

Get even more Code Suggestions with customizable language settings

In the GitLab VS Code Workflow extension, you now have the option to configure additional languages for code suggestions.

This feature is an experiment. To learn more and get started, see our VS Code Workflow extension settings.

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.0.

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.

  • Remove `previousStageJobsOrNeeds` from GraphQL
  • GraphQL API access through unsupported methods
  • 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.

    • GraphQL API access through unsupported methods
    • SAST analyzer coverage changing in GitLab 17.0
    • Upgrading the operating system version of GitLab SaaS runners on Linux
    • npm package uploads now occur asynchronously
    • Secure analyzers major version update
    • Autogenerated Markdown anchor links with dash (`-`) characters
    • Rename the 'require_password_to_approve' field
    • 'repository_download_operation' audit event type for public projects
    • Agent for Kubernetes option `ca-cert-file` renamed
    • Scan execution policies enforcing scans with an `_EXCLUDED_ANALYZERS` variable will override project variables
    • Deprecate `fmt` job in Terraform Module CI/CD template
    • Deprecate `version` field in feature flag API
    • Deprecating Windows Server 2019 in favor of 2022
    • Deprecate Python 3.9 in Dependency Scanning and License Scanning
    • Removal of tags from small SaaS runners on Linux
    • Support for self-hosted Sentry versions 21.4.1 and earlier
    • Min concurrency and max concurrency in Sidekiq options
    • Maven versions below 3.8.8 support in Dependency Scanning and License Scanning
    • Security policy field `match_on_inclusion` is deprecated
    • Deprecate License Scanning CI templates
    • Dependency Scanning incorrect SBOM metadata properties
    • Deprecate Grype scanner for Container Scanning
    • Deprecate custom role creation for group owners on self-managed
    • `dependency_files` is deprecated
    • Compliance framework in general settings
    • `omniauth-azure-oauth2` gem is deprecated
    • Heroku image upgrade in Auto DevOps build
    • `after_script` keyword will run for cancelled jobs
    • License Scanning support for sbt 1.0.X
    • `metric` filter and `value` field for DORA API
    • License List is deprecated
    • Support for setting custom schema for backup is deprecated
    • Dependency Scanning support for sbt 1.0.X
    • GitLab Runner provenance metadata SLSA v0.2 statement
    • Proxy-based DAST deprecated
    • List repository directories Rake task
    • JWT `/-/jwks` instance endpoint is deprecated
    • GraphQL: deprecate support for `canDestroy` and `canDelete`
    • Deprecate change vulnerability status from the Developer role
    • File type variable expansion fixed in downstream pipelines
    • Legacy Geo Prometheus metrics
    • The GitHub importer Rake task
    • Offset pagination for `/users` REST API endpoint is deprecated
    • Container registry support for the Swift and OSS storage drivers
    • Security policy field `newly_detected` is deprecated
    • Internal container registry API tag deletion endpoint
    • `postgres_exporter['per_table_stats']` configuration setting
    • Geo: Legacy replication details routes for designs and projects deprecated
    • GraphQL field `totalWeight` is deprecated
    • Deprecate field `hasSolutions` from GraphQL VulnerabilityType
    • Twitter OmniAuth login option is deprecated from self-managed GitLab
    • GraphQL field `registrySizeEstimated` has been deprecated
    • OmniAuth Facebook is deprecated
    • Deprecated parameters related to custom text in the sign-in page
    • The pull-based deployment features of the GitLab agent for Kubernetes is deprecated
    • Deprecate `CiRunner` GraphQL fields duplicated in `CiRunnerManager`
    • `omnibus_gitconfig` configuration item is deprecated
    • Deprecate Windows CMD in GitLab Runner
    • Unified approval rules are deprecated
    • Duplicate storages in Gitaly configuration
    • Deprecate `message` field from Vulnerability Management features
    • GraphQL deprecation of `dependencyProxyTotalSizeInBytes` field
    • GraphQL type, `RunnerMembershipFilter` renamed to `CiRunnerMembershipFilter`
    • PostgreSQL 13 no longer supported
    • CiRunner.projects default sort is changing to `id_desc`
    • Trigger jobs can mirror downstream pipeline status exactly
    • Required Pipeline Configuration is deprecated
    • Queue selector for running Sidekiq is deprecated
    • HashiCorp Vault integration will no longer use CI_JOB_JWT by default
    • Old versions of JSON web tokens are deprecated
    • The Visual Reviews tool is deprecated
    • Maintainer role providing the ability to change Package settings using GraphQL API
    • GitLab Helm chart values `gitlab.kas.privateApi.tls.*` are deprecated
    • Auto DevOps support for Herokuish is deprecated
    • GraphQL: The `DISABLED_WITH_OVERRIDE` value of the `SharedRunnersSetting` enum is deprecated. Use `DISABLED_AND_OVERRIDABLE` instead
    • The `gitlab-runner exec` command is deprecated
    • DAST ZAP advanced configuration variables deprecation
    • GraphQL field `confidential` changed to `internal` on notes
    • Vulnerability confidence field
    • DingTalk OmniAuth provider
    • PipelineSecurityReportFinding projectFingerprint GraphQL field
    • GraphQL networkPolicies resource deprecated
    • Package pipelines in API payload is paginated
    • Other notable changes Other notable changes

      Contributions to Git 2.45

      Contributions to Git 2.45

      Our team members made significant contributions to Git 2.45.0. Here are a few.

      Reftables reference backend

      Up to now, Git kept track of branches and tags (which both fall into the category of “references” or “refs”) in loose files in the .git directory. Git can also pack these up into a single “packed-refs” file. This can lead to:

      • Performance bottlenecks for those running monorepositories that have many references.
      • Race conditions when references are updated or deleted concurrently, leading to secondaries getting out of sync.

      Reftables is a next generation backend format for references that stores them not in loose files, but in an indexed, binary file format. This format both scales with a large number of references, and allows atomic updates.

      The format was originally designed by Shawn Pearce in July 2017, and in 2021 a reftable library was upstreamed by Han-Wen Neinhuys, but was not integrated into the Git project. The Gitaly team got a significant number of changes merged including test refactoring, tooling, prepping the code base to integrate the reftable backend, and many code optimizations to the original implementation.

      The result is that with Git 2.45.0, reftables is now usable! This enables GitLab to run our Git servers with reftables as the references backend for repositories, leading to improved performance for large monorepositories.

      Better tooling for references

      With the introduction of the reftable backend, tooling was also needed to inspect the references given it stores refs in a binary format.

      Better tooling for references

      Because the reftable backend stores references in a binary format rather than loose files, we improved Git’s tooling for inspecting refs to allow users to inspect refs when using reftable.

      A new flag was added to git-for-each-ref(1) called --include-root-refs, which will cause it to also list all references that exist in the root of the reference-naming hierarchy. For example:

      sh $ git for-each-ref --include-root-refs f32633d4d7da32ccc3827e90ecdc10570927c77d commit HEAD f32633d4d7da32ccc3827e90ecdc10570927c77d commit MERGE_HEAD f32633d4d7da32ccc3827e90ecdc10570927c77d commit refs/heads/main

      Listing all reflogs

      The reflog in Git tracks any modifications to references and is useful for debugging what changed in a given reference. Reflogs are kept in loose files in the .git/logs directory, which can be inspected manually to list all log entries.

      With the reftable format, these logs are no longer stored in the .git/logs directory, making it impossible to inspect through the filesystem.

      Git lacked a command to list all reflogs in the directory. To address this problem, a new command (git-reflog-list(1)) was added to list all reflogs, which works with the reftable format.

      More efficient packing of references

      When the reftable backend is used to add or modify a ref, Git will perform “auto-compaction”, which merges tables together as needed.

      A --auto flag was added to git-pack-refs(1), which allows it to skip reftable compaction when Git detects that the reference database is already in an optimal state.

      git-maintenance(1) has also been adapted to pass this flag when it calls git-pack-refs(1) to make use of this new mode by default.

      Important notes on upgrading to GitLab Important notes on upgrading to GitLab 17.0

      Before upgrading to GitLab 17.0, if you use Sentry to track errors in your GitLab environments, you must upgrade your Sentry instance to version 21.5.0 or later. For more information, see the relevant documentation.


      You must first upgrade to GitLab 16.11 before upgrading to GitLab 17.0 to allow background migrations to finish.


      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