gitlab-org/gitlab-foss v17.6.0

on GitLab

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!

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.

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!

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.

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.