gitlab-org/gitlab-foss v16.9.0

on GitLab

The Environment auto_stop_in functionality was updated to run the job from the last finished pipeline, instead of the last successful pipeline. This avoids edge cases where the auto stop job can not run because of not having any successful pipelines.

This behaviour might be considered a breaking change in some situations. The new behaviour is currently behind a feature flag, and will become the default in 17.0, and at the same time, we are going to deprecate the old behaviour to be removed from GitLab in 18.0. We recommend everyone to start transitioning or to configure the feature flag immediately to minimize the risks of the breaking change at the first 17.x upgrade.

This release adds full support for Kubernetes version 1.29, released in December 2023. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.

You can read more about our Kubernetes support policy and other supported Kubernetes versions.

Administrators can now add text guidelines that are visible to users with permissions to manage members on the Members page of a group or project. Administrators can access these guidelines in the Appearance section of the Admin Area settings.

Guidelines are helpful for teams that use external tooling to manage members of groups or projects. For instance, the guideline can link to predefined groups that users should use instead of managing membership for individual members.

Thank you @bufferoverflow for this community contribution!

Completed migrations of GitLab groups and projects by direct transfer have displayed badges (Complete, Partially completed, and Failed) to inform users about the general end result of the migration. Users could also access a list of items that were not imported, by clicking on the See failures link.

However, for a partially-imported project, there was no quick way to understand how many items of each type were successfully imported and how many were not.

In this release, we added import results statistics for groups and projects. To access the statistics, select the Details link on the direct transfer history page.

With this release, we've added REST API support for the GitLab for Slack app.

You cannot create a GitLab for Slack app from the API. Instead, you must install the app from the GitLab UI. You can then retrieve the integration settings and update or disable the app for a project.

In GitLab 16.2, we released the rich text editor as an alternative to the plain text editor. The rich text editor provides a "what you see is what you get" editing interface, and an extensible foundation for additional development. Until this release, however, the rich text editor was available only in issues, epics, and merge requests.

With GitLab 16.9, the rich text editor is now available in:

• Requirements descriptions
• Vulnerability findings
• Release descriptions
• Design notes

With improved access to the rich text editor, you can collaborate more efficiently and without previous Markdown experience.

The last part of reviewing a merge request is communicating the outcome. While approving was unambiguous, leaving comments was not. They required the author to read your comments, then determine if the comments were purely informational, or described needed changes. Now, when you complete your review, you can select from three options:

• Comment: Submit general feedback without explicitly approving.
• Approve: Submit feedback and approve the changes.
• Request changes: Submit feedback that should be addressed before merging.

The sidebar now shows the outcome of your review next to your name. Currently, ending your review with Request changes doesn't block the merge request from being merged, but it provides extra context to other participants in the merge request.

You can leave feedback about the Request changes feature in our feedback issue.

We’re also releasing GitLab Runner 16.9 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:

• Make Kubernetes API retries configurable

Bug Fixes:

• Random warning: failed to remove ***: Directory not empty

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

If you use branch pipelines, you can now quickly view and access the related merge requests from the pipeline details page.

In GitLab 16.9, we have released a series of improvements to the CI/CD variables user experience. We have improved the variables creation flow through changes including:

• Improved validation when variable values do not meet the requirements.
• Help text during variable creation.
• Allow resizing of the value field in the variables form.

Other improvements include a new, optional description field for group and project variables to assist with the management of variables. We have also made it easier to add or edit multiple variables, lowering the friction in the software development workflow and enabling developers to perform their job more efficiently.

Your feedback for these changes is always valued and appreciated.

Currently, to use the auto-cancel redundant pipeline feature, you must set jobs that can be cancelled as interruptible: true to determine whether or not a pipeline can be cancelled. But this only applies to jobs that are actively running when GitLab tries to cancel the pipeline. Any jobs that have not yet started (are in "pending" status) are also considered safe to cancel, regardless of their interruptible configuration.

This lack of flexibility hinders users who want more control over which exact jobs can be cancelled by the auto-cancel pipeline feature. To address this limitation, we are pleased to announce the introduction of the auto_cancel:on_new_commit keywords with more granular control over job cancellation. If the legacy behavior did not work for you, you now have the option to configure the pipeline to only cancel jobs that are explicitly set with interruptible: true, even if they haven't started yet. You can also set jobs to never be automatically cancelled.

You can use the GitLab package registry to publish and download Terraform modules. By default, you cannot publish the same module name and version more than once per project.

However, you might want to allow duplicate uploads, especially for releases. In this release, GitLab expands the group setting for the package registry so you can allow or deny duplicate modules.

When using the GitLab Terraform registry, it is important to have a cross-project view of all your modules. Until recently, the user interface has been available only at the project level. If your group had a complex structure, you might have had difficulty finding and validating your modules.

From GitLab 16.9, you can view all of your group and subgroup modules in GitLab. The increased visibility provides a better understanding of your registry, and decreases the likelihood of name collisions.

We've updated more than 40 default GitLab SAST rules to:

• Increase true-positive results (correctly identified vulnerabilities) and reduce false-negative results (incorrectly identified vulnerabilities) by updating the detection logic rules for C#, Go, Java, JavaScript, and Python.
• Add OWASP mappings for C#, Go, Java, and Python rules.

The rule changes are included in updated versions of the Semgrep-based GitLab SAST analyzer. This update is automatically applied on GitLab 16.0 or newer unless you've pinned SAST analyzers to a specific version. We're working on more SAST rule improvements in epic 10907.

Self-managed users can now seamlessly access Service Ping data through a REST API connection, facilitating direct integration with downstream systems. This represents a significant improvement over the previous method of file download. The new approach offers self-managed users a more efficient and real-time means of conducting customized analysis and deriving specific insights from their GitLab usage data.