GitLab.org/GitLab: Release v17.6.0-ee

You can now create, test, and deploy applications for the newest generations of Apple devices using macOS Sequoia 15 and Xcode 16.

GitLab's hosted runners on macOS help your development teams build and deploy macOS applications faster in a secure, on-demand build environment integrated with GitLab CI/CD.

Try it out today by using the macos-15-xcode-16 image in your .gitlab-ci.yml file.

You can now host selected large language models (LLMs) in your own infrastructure and configure those models as the source for GitLab Duo Chat. This feature is in beta and available with an Ultimate and Duo Enterprise subscription on self-managed GitLab environments.

With self-hosted models, you can use models hosted either on-premise or in a private cloud as the source for GitLab Duo Chat or Code Suggestions (introduced as a beta feature in GitLab 17.5). For 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. For Chat, we currently support open-source Mistral models on vLLM or AWS Bedrock, and Claude 3.5 Sonnet on AWS Bedrock. 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 501268.

As a GitLab Dedicated tenant administrator, you can now use Switchboard to set up outbound private links and private hosted zones. You can also monitor your network connections by viewing periodic snapshots in Switchboard.

Outbound private links and private hosted zones establish secure network connectivity between resources in your AWS account and GitLab Dedicated.

Prior to this release, it was not possible to get GitLab Duo Chat and Code Suggestions usage data per Duo Enterprise user. In 17.6, we've added a GraphQL API to provide visibility into the number of code suggestions accepted and Duo Chat interactions for each active Duo Enterprise user. The API can help you get more granular insight into who is using which Duo Enterprise features and how frequently. This is the first iteration toward our goal of providing more comprehensive Duo Enterprise usage data within GitLab.

In GitLab 17.6, we added support for the Exploit Prediction Scoring System (EPSS). EPSS gives each CVE a score between 0 and 1 indicating the probability of the CVE being exploited in the next 30 days. You can leverage EPSS to better prioritize scan results and to help evaluate the potential impact a vulnerability may have on your environment.

This data is available to composition analysis users through GraphQL.

It's now easier to programatically enable secret push protection. We've updated the application settings REST API, allowing you to:

1. Enable the feature in your self-managed instance so that it can be enabled on a per-project basis.
2. Check whether the feature has been enabled on a project.
3. Enable the feature for a specified project.

Audit events are now logged when a secret push protection exclusion is applied. This enables security teams to audit and track any occurence when a secret on the project's exclusions list is allowed to be pushed.

The License Scanner now has the ability to consume a dependency's license from a CycloneDX SBOM that includes supported package types.

In cases where the licenses field of a CycloneDX SBOM is available, users will see license data from their SBOM. In cases where the SBOM lacks license information we will continue to provide this data from our License database.

With this release, when a merge request is merged, a new audit event type called merge_request_merged is triggered that contains key information about the merge request, including:

• The title of the merge request
• The description or summary of the merge request
• How many approvals were required for merge
• How many approvals were granted for merge
• Which users approved the merge request
• Whether committers approve the merge request
• Whether authors approved the merge request
• The date/time of the merge
• The list of SHAs from Commit history

GitLab offers a wide range of security scanners such as SAST, secret detection, dependency scanning, container scanning, and more so that you can check your applications for security vulnerabilities.

You need to have a way to show auditors and relevant compliance authorities that your applications have adhered to regulatory standards that require you to have security scanners set up for your repositories.

To help you demonstrate adherence to these standards, this release includes two new checks as part of the standard adherence report in the Compliance Centre. These new checks check whether SAST and DAST has been enabled for projects within a group. The checks confirm that the SAST and DAST security scanners correctly ran in a project and the pipeline results has the correct resulting artifacts.

When a merge request approval policy is configured to prevent group branch modification, policies now account for protected branches configured for a group. This setting ensures that branches protected at the group level cannot be unprotected. Protected branches restrict certain actions, such as deleting the branch and force pushing to the branch. You can override this behavior and declare exceptions for specific top-level groups with the new approval_settings.block_group_branch_modification property to allow group owners to temporarily modify protected branches when necessary.

This new project override setting ensures that group protected branch settings cannot be modified to circumvent security and compliance requirements, ensuring more stable enforcement of protected branches.

Users require the ability to view vulnerabilities in groups. This will help security analysts optimize their triage tasks by utilizing bulk actions. In addition users can see how many vulnerabilities match their group; i.e. how many OWASP Top 10 vulnerabilities are there?

In this release, we've added project events to group webhooks. Project events are triggered when:

• A project is created in a group.
• A project is deleted in a group.

These events are triggered for group webhooks only.

In previous versions of GitLab, the user list displayed on the GitLab Duo seat assignment page could not be filtered, making it difficult to see which users had previously been assigned a GitLab Duo seat. Now, you can filter your user list by Assigned seat = Yes or Assigned seat = No to see to see which users are currently assigned or not assigned a GitLab Duo seat, allowing for ease in adjusting seat allocations.

All users on self-managed instances will receive an email when they are assigned a GitLab Duo seat.

Previously, those assigned a Duo Enterprise seat or those granted access by bulk assignment would not be notified. You wouldn't know you were assigned a seat unless someone told you, or you noticed new functionality in the GitLab UI.

To disable this email, an administrator can disable the duo_seat_assignment_email_for_sm feature flag.

GitLab Duo Pro customers can now programmatically access AI Impact Analytics metrics with the aiMetrics GraphQL API. Metrics include the number of assigned GitLab Duo seats, Duo Chat users, and Code Suggestion users. The API also provides granular counts for code suggestions that are shown and accepted. With this data, you can calculate the acceptance rate for Code Suggestions, and better understand your Duo Pro users' adoption of Duo Chat and Code Suggestions. You can also pair AI Impact Analytics metrics with Value Stream Analytics and DORA metrics to gain deeper insight into how adopting Duo Chat and Code Suggestions are impacting your team's productivity.

Repository X-Ray enriches code generation requests for GitLab Duo Code Suggestions by providing additional context about a project's dependencies to improve the accuracy and relevance of code recommendations. This improves the quality of code generation. Previously, Repository X-Ray used a CI job that you had to configure and manage.

Now, when a new commit is pushed to your project's default branch, Repository X-Ray automatically triggers a background job that scans and parses the applicable configuration files in your repository.

The latest update to the GitLab Duo plugin introduces advanced proxy authentication. This enables developers to connect seamlessly in environments with strict corporate firewalls. Building on our existing HTTP proxy support, this enhancement allows for authenticated connections. It ensures secure and uninterrupted access to Duo features in VS Code and JetBrains IDEs.

This update is crucial for developers needing secure, authenticated connections in restricted network environments. It ensures all Duo features remain available without compromising security.

After you've carefully crafted your changes and prepared a merge request, the next step is to identify reviewers who can help move it forward. Identifying the right reviewers for your merge request involves understanding who the right approvers are, and who might be a subject matter expert (CODEOWNER) for the changes you're proposing.

Now, when assigning reviewers, the sidebar creates a connection between the approval requirements for your merge request and reviewers. View each approval rule, then select from approvers who can satisfy that approval rule and move the merge request forward for you. If you use optional CODEOWNER sections those rules are also shown in the sidebar to help you identify appropriate subject matter experts for your changes.

Enhanced reviewer assignments is the next evolution of applying intelligence to assigned reviewers in GitLab. This iteration builds on what we've learned from suggested reviewers, and how to effectively identify the best reviewers for moving a merge request forward. In upcoming iterations of reviewer assignments, we'll continue to enhance the intelligence used to recommend and rank possible reviewers.

GitLab workspaces now offer support for private container registries. With this setup, you can pull container images from any private registry of your choice. As long as your Kubernetes cluster has a valid image pull secret, you can reference the secret in your GitLab agent configuration.

This feature simplifies workflows, especially for teams that use custom or third-party container registries, and improves the flexibility and security of containerized development environments.

The extension marketplace is now available in workspaces. With the extension marketplace, you can discover, install, and manage third-party extensions to enhance your development experience. Choose from thousands of extensions to boost your productivity or customize your workflow.

The extension marketplace is disabled by default. To get started, go to your user preferences and enable the extension marketplace. For enterprise users, only users with the Owner role for a top-level group can enable the extension marketplace.

With this release, a workspace now stops rather than terminates after the configured timeout has elapsed. This feature means you can always restart your workspaces and pick up where you left off.

By default, a workspace automatically:

• Stops 36 hours after the workspace was last started or restarted
• Terminates 722 hours after the workspace was last stopped

You can configure these settings in your GitLab agent configuration.

With this feature, a workspace remains available for approximately one month after it was stopped. This way, you get to keep your progress while optimizing workspace resources.

Currently, only administrators can create service accounts on GitLab self-managed. Now, there is an optional setting which allows top-level group Owners to create service accounts. This allows administrators to choose if they would like a wider range of roles that are allowed to create service accounts, or keep it as an administrator-only task.

Service accounts now have a designated badge and can be easily identified in the users list. Previously, these accounts only had the bot badge, making it difficult to distinguish between them and group and project access tokens.

In the last release, we introduced support for easy agent bootstrapping to the GitLab CLI tool. GitLab 17.6 further improves the glab cluster agent bootstrap command with support for custom Helm values. You can use the --helm-release-values and --helm-release-values-from flags to customize the generated HelmRelease resource.

To use the dashboard for Kubernetes, you need to select an agent for Kubernetes connection from the environment settings. Until now, you could select the agent only from the UI or (from GitLab 17.5) the API, which made configuring a dashboard from CI/CD difficult. In GitLab 17.6, you can configure an agent connection with the environment.kubernetes.agent syntax. In addition, issue 500164 proposes to add support for selecting a namespace and Flux resource from your CI/CD configuration.

Have you ever wondered what might be included in a deployment you've been asked to approve? In past versions, you could create a release with a detailed description about its content and instructions for testing, but the related environment-specific deployment did not show this data. We are happy to share that GitLab now displays the release notes under the related deployment details page.

Because GitLab releases are always created from a Git tag, the release notes are shown only on deployments related to the tag-triggered pipeline.

This feature was contributed to GitLab by Anton Kalmykov. Thank you!

To give you more flexibility in designing your pipelines, you no longer need to name your Pages deploy job pages. You can now simply use the pages attribute in any CI/CD job to trigger a Pages deployment.

You can now hide closed items from the linked and child items lists by turning off the Show closed items toggle. With this addition, you have greater control over your view and can focus on active work while reducing visual clutter in complex projects.

Some merge requests may need to be held for merging until after a certain date or time. When that date and time does pass you need to find someone with permissions to merge and hope they're available to take care of it for you. If this is after hours or the timeline is critical you may need to prepare folks well in advance for the task.

Now, when you create or edit a merge request you can specify a merge after date. This date will be used to prevent the merge request from being merged until it has passed. Using this new capability with our previously released improvements to auto-merge gives you the flexibility to schedule merge requests to merge in the future.

A big thank you to Niklas van Schrick for the amazing contribution!

You can now see JaCoCo test coverage results directly in your merge request diff view. This visualization allows you to quickly identify which lines are covered by tests and which need additional coverage before merging.

We’re also releasing GitLab Runner 17.6 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.

Bug Fixes:

• In GitLab Runner 17.5.0, pods fail to become attachable
• Runner crashes with exec format error when installing the fleeting plugin
• Kubernetes executor pods with cgroup v2 enabled hang when OOMKilled
• Runner defaults are not honoured when registering runner with a configuration template
• GitLab Runner waits for Kubernetes pods to become attachable during the polling period when using exec mode
• Authentication issues occur when the feature flag FF_GIT_URLS_WITHOUT_TOKENS is enabled

There are now additional audit events for privileged settings-related administrator actions. A record of when these settings were changed can help improve security by providing an audit trail.

It is now possible to disable the OTP authenticator and WebAuthn devices individually or simultaneously. Previously, if you disabled the OTP authenticator, the WebAuthn device(s) were also disabled. Because the two now operate independently, there is more granular control over these authentication methods.

Administrators can use the new token information API to get information about personal access tokens, deploy tokens, and feed tokens. Unlike other API endpoints that expose token information, this endpoint allows administrators to retrieve token information without knowing the type of the token.

Thank you Nicholas Wittstruck and the rest of the crew from Siemens for your contribution!

GitLab optionally sends an email when a sign-in from a new location is detected. Previously, this email only contained the IP address, which is difficult to correlate to a location. This email now contains city and country location information as well.

Thank you Henry Helm for your contribution!

Previously, we announced that the default CI/CD job token (CI_JOB_TOKEN) behavior will change in GitLab 18.0, requiring you to explicitly add indvidual projects or groups to your project's job token allowlist if you want them to continue to be able to access your project.

Now, we are giving self-managed and Dedicated instance administrators the ability to enforce this more secure setting on all projects on an instance. After you enable this setting, all projects will need to make use of their allowlist if they want to use CI/CD job tokens for authentication. Note: We recommend enabling this setting as part of a strong security policy.

Previously it was difficult to track which other projects were using accessing your project by authenticating with CI/CD job tokens. To make it easier for you to audit and control access to your project, we've added an authentication log.

With this authentication log, you can view the list of other projects that have used a job token to authenticate with your project, both in the UI and as a downloadable CSV file. This data can be used to audit project access and aid in populating the job token allowlist to enable stronger control over which projects can access your project.

GitLab's model registry, now generally available, is your centralized hub for managing machine learning models as part of your existing GitLab workflow. You can track model versions, store artifacts and metadata, and maintain comprehensive documentation in the model card.

Built for seamless integration, the model registry works natively with MLflow clients and connects directly to your CI/CD pipelines, enabling automated model deployment and testing. Data scientists can manage models through an intuitive UI or existing MLflow workflows, while MLOps teams can leverage semantic versioning and CI/CD integration for streamlined production deployments all within the GitLab API.

Please feel free to drop us a note in our feedback issue and we'll get back in touch! Get started today by going to Deploy > Model registry in your GitLab instance.