GitLab 17.6 release notes

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.

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.

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!

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.

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.

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.