GitLab 17.0 release notes

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.

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 two databases by default. In 16.0, two database connections became the default for self-managed installations. 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 to two databases 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.

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.

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

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.

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!

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.

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

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.

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.

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

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.

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!

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

• Assign security policy links
• Manage and assign compliance frameworks
• Manage webhooks
• Manage push rules

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.

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.

A series of improvements have been made to the user experience for custom roles, specifically:

• A new page opens when creating a new custom role.
• Improved design for the custom role table.
• Improved design for the delete custom role dialog.
• Precheck permissions of the base role.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

• Documentation for installing the Runner Operator in disconnected network environments

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