GitLab 16.7 release notes

Until now, GitLab only displayed time in 12 hour format, which could not be changed.

From this release, thanks to the community contribution, you can customize the format used to display time in places like issue lists, overview pages or when setting your status. You can display times as:

• 12 hour format, for example 2:34 PM.
• 24 hour format, for example 14:34.

Thanks to Thorben Westerhuys for this community contribution!

In the following milestone we will audit all timestamps shown across the GitLab product to make them respect the setting.

GitLab groups and project migrations done by direct transfer can become stuck for various reasons. In the past, to avoid leaving these migrations in an incomplete state indefinitely, GitLab periodically executed a worker to identify migrations that hadn’t completed within 8 hours. GitLab marked these migrations as timed out.

For large organizations, the migration process can take longer than 8 hours, so this amount of time was not always sufficient to properly determine if a migration was stuck. As a result, this worker might have incorrectly marked a migration as stuck.

In this milestone, instead of using an 8 hour time limit, GitLab now only marks the migration as stuck if the child workers stop working for 24 hours.

Knowing how crucial for our users is to understand the results of the import process, in this milestone we further improved on information presented for imports by direct transfer. We now display import status badges next to GitLab groups and projects on:

• The page where you can select groups and projects to import.
• The page listing imported groups and projects.

The import status badges are:

• Not started
• Pending
• Importing
• Failed
• Timeout
• Cancelled
• Complete
• Partially completed

The Partially completed badge was added in this release and identifies a completed import process that has some items (such as merge requests or issues) not imported.

Groups that an import process was started for have a View details link that shows imported subgroups and projects for that particular group. From there, you can see the list of items that couldn’t be imported (if any) by clicking a See failures link. See failures was released in the last release.

In this milestone we also improved navigation with the breadcrumbs between those pages.

You can now configure GitLab to reopen closed issues when an external participant adds a new comment on an issue by email. This gives you full visibility into ongoing conversations, even after an issue has been resolved.

It also adds an internal comment that mentions the assignees of the issue and creates to-do items for them. This way you can make sure you never miss a follow-up email again.

GitLab merge request dependencies are a great way to ensure that code changes that rely on other changes aren’t merged in a way that could break the codebase. Previously, GitLab didn’t allow complex dependency chains, which could result in circular references or deep nesting.

The limitations around dependency hierarchy, and items in the chain, have been removed. Merge request dependencies can now be more complex: a single merge request can be blocked by up to 10 merge requests, and in turn, block to 10 other merge requests. Deeper dependency chains make it possible to represent more complex workflows via dependencies. We’re excited to see how you continue to expand your usage of this feature.

When your approval is required for a merge request, you need to be notified to take action. Some users only want notifications when their approval is required, which is typically done by adding a user by name to review the changes. However, some users want a notification for any merge request they are eligible to approve, even if they aren’t added by name as reviewers.

Enable the Added as approver custom notification level to trigger an email and to-do for each merge request you are eligible to approve. This helps you be aware of merge requests sooner in the process, and take action to get the proposal merged.

If you’re switching from Terraform to OpenTofu, this release of GitLab adds preliminary support for OpenTofu. Because OpenTofu is a fork of Terraform, the MR widget integration, module registry, and GitLab-managed Terraform state work by default. We added support for OpenTofu in the gitlab-terraform helper image to simplify the usage of the GitLab IaC offering.

GitLab continues to support Terraform for the MR widget, module registry, and GitLab-managed Terraform state.

CI/CD variable precedence has been improved to first prioritize variables defined in scan execution policies.

As organizations work to meet compliance requirements, a common need is to ensure that security scanners are enabled in business critical applications.

Scan execution policies allow teams to enforce scanners and to define default and custom CI/CD variables. With this enhancement to CI/CD variable precedence, teams can be confident that regardless of how pipelines are triggered, the variables defined with compliance in mind remain intact.

In GitLab 16.2 we released the rich text editor as an alternative to the existing Markdown editing experience. The rich text editor provides a “what you see is what you get” editing experience and an extensible foundation on which we can build custom editing interfaces for things like diagrams, content embeds, media management, and more.

With GitLab 16.7, we’ve changed the rich text editor to match the behavior with our Markdown editing experience and fix reported bugs. We’ve changed the sorting order in the labels autocomplete modal to be consistent between the Markdown and rich-text editor, addressed a bug in the options returned in the unassign quick action in the rich-text editor, added support for custom emojis, and updated the look and feel of the quick action selection dropdown to be consistent in the two editing experiences, among other improvements.

Previously, the Container Registry relied on the Docker/OCI listing image tags registry API to list and display tags in GitLab. This API had significant performance and discoverability limitations.

This API performed slowly because the number of network requests against the registry scaled with the number of tags in the tags list. In addition, because the API didn’t track publish time, the published timestamp was often incorrect. There were also limitations when displaying images based on Docker manifest lists or OCI indexes, such as for multi-architecture images.

To address these limitations, we introduced a new registry list repository tags API. By updating the user interface to use the new API, the number of requests to the Container Registry is reduced to just one. Publish timestamps are also accurate, and there is more robust support for multi-architecture images.

This feature is available only on GitLab.com. Self-managed support is blocked until the next-generation Container Registry is generally available. To learn more, see issue 423459.

Before this release, you could not rename a project that had a container repository with at least one tag without having first deleted all container images associated with that project.

This was a real problem that forced users to rely on custom scripts to manually delete/move all tags before a different project name could be used, but now you can rename projects on GitLab.com, even if they have container images in the registry!

During the 16.7 release milestone, we enabled the following active checks for browser-based DAST by default:

• Check 89.1 replaces ZAP checks 40018, 40019, 40020, 40021, 40022, 40024, 40027, 40033, and 90018 and identifies SQL Injection.
• Check 918.1 replaces ZAP check 40046 and identifies Server Side Request Forgery.
• Check 98.1 replaces ZAP check 7 and identifies PHP Remote File Inclusion.
• Check 917.1 replaces ZAP check 90025 and identifies Expression Language Injection.
• Check 1336.1 replaces ZAP check 90035 and Server-Side Template Injection.

We’ve updated the default ruleset used in GitLab SAST to provide higher-quality results. We analyzed each rule that was previously included by default, then removed rules that did not provide enough value in most codebases.

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.

Existing scan results from the removed rules are automatically resolved after your pipeline runs a scan with the updated analyzer.

We’re working on more SAST rule improvements in epic 10907.

In GitLab 13.0 we introduced the ability to keep the job artifacts from the most recent successful pipeline. Unfortunately, the feature also marked all failed and blocked pipelines as the latest pipeline regardless of whether they were the most recent or not. This led to a buildup of artifacts in storage which had to be deleted manually.

In GitLab 16.7 the bugs causing this unintended behavior are resolved. Job artifacts from failed and blocked pipelines are only kept if they are from the most recent pipeline, otherwise they will follow the expire_in configuration. Affected GitLab.com customers should see artifacts which were inadvertently kept now unlocked and removed after a new pipeline run.

The Keep artifacts from most recent successful jobs setting overrides the job’s artifacts: expire_in configuration and can result in a large number of artifacts stored without expiry. If your pipelines create many large artifacts, they can fill up your project storage quota quickly. We recommend disabling this setting if this feature is not required.

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

• Implement graceful shutdown for Docker executor
• Dynamically create PVC volumes with storage classes for Kubernetes

Bug Fixes:

• allow_failure:exit codes unusable with custom executor because exit code is always 1
• Add better handling of signals in the runner helper and build container for the Kubernetes executor

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