GitLab 16.6 release notes

Previously, when migrating GitLab projects and groups by direct transfer had completed and some items (such as a merge requests or issues) were not successfully imported, you could select a Details button on the page listing imported groups and projects and see related errors there.

However, a list of errors is not helpful to understand how many items in total, and which items in particular, were not imported. Having this information is crucial to understanding the results of the import process.

In this release, we replaced the Details button with a See failures link. Selecting the See failures link takes you to a new page listing all items that failed to import for a given group or project. For each item that wasn’t imported, you can see:

• The type of the item. For example, merge request or issue.
• What kind of error occurred.
• The correlation ID, which is useful for debugging purposes.
• The URL of the item on the source instance, if available (items with iid).
• The title of the item on the source instance, if available. For example, the merge request title or the issue title.

The 16.0 release introduced a new navigation experience, which became the default for all users on June 2, 2023. In subsequent milestones, many improvements were made based on a wealth of user feedback. The ability to fall back to the old navigation has now been removed. More exciting changes are planned for the navigation, but for now, all users have a consistent navigation experience.

As a recap, with the new GitLab navigation, you can:

• Pin menu items to save your most-used project or group items at the top
• Hide and “peek” the navigation to expose a wider screen
• Easily search for menu items by using keyboard shortcuts
• Continue to use all the themes you had with the previous navigation
• Use better-organized sections that align with a DevOps workflow

From GitLab version 16.4, you can connect to a Kubernetes cluster from a local terminal using the agent for Kubernetes and a personal access token. In the initial version, setting up the local cluster configuration required several commands and a long lived access token. In the past month, we worked to streamline and improve the security of the set up process by extending the GitLab CLI.

The GitLab CLI can now list the agent connections available from a GitLab project checkout directory or the specified project. You can set up the connection through a selected agent with a dedicated command. When kubectl or any other tool needs to authenticate with the cluster, the GitLab CLI generates a temporary, restricted token for the signed-in user.

One of several new settings being added to scan result policies to aide in compliance enforcement of security policies, this control will limit the ability to leverage project-level settings to circumvent policies.

For each existing or new scan result policy, you can enable Prevent pushing and force pushing to take effect for the branches defined within the policy to prevent users from circumventing the merge request flow to push changes directly to a branch.

Available in SaaS in 16.6. Available for Self-managed behind the feature flag scan_result_policies_block_force_push and will be enabled by default in 16.7.

Building on our integrations with external logging or data aggregation tools, you can now select AWS S3 as a destination for audit event streams for top-level groups. This feature provides relevant information for an easier and more trouble-free integration.

Previously, you had to use custom HTTP headers to try to build a request that AWS S3 would accept. This method was prone to errors and could be difficult to troubleshoot.

Previously, external status checks on MRs continued to poll the external URL until they received either a successful or failed response. This could result in some status checks seeming to hang in an unresponsive state.

Now, a 2 minute timeout has been incorporated so that you can manually retry the status check after 2 minutes if you are not getting any response from the external system.

You can use the GitLab Package Registry to publish and download your project’s NuGet packages. By default, you can publish the same package name and version multiple times.

However, you might want to prevent duplicate uploads, especially for releases. In this release, GitLab has expanded the group setting for the Package Registry so you can allow or deny duplicate package uploads.

You can adjust this setting with the GitLab API, or from the UI.

The GitLab Package Registry now supports uploading Maven packages with basic HTTP authentication. Previously, you could use basic HTTP authentication only to download Maven packages. This inconsistency made it difficult for developers to configure and maintain authentication for their project.

Publishing artifacts with sbt is not supported, but issue 408479 proposes to add this feature.

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

• Check 94.1 replaces ZAP check 90019 and identifies server-side code injection (PHP).
• Check 94.2 replaces ZAP check 90019 and identifies server-side code injection (Ruby).
• Check 94.3 replaces ZAP check 90019 and identifies server-side code injection (Python).
• Check 943.1 replaces ZAP check 40033 and identifies improper neutralization of special elements in data query logic.
• Check 74.1 replaces ZAP check 90017 and identifies XSLT injection.

Teams can now seamlessly create, test, and deploy applications for the Apple ecosystem on macOS 14 and Xcode 15.

SaaS runners on macOS allow you to increase your development teams’ velocity in building and deploying applications that require macOS in a secure, on-demand GitLab Runner build environment integrated with GitLab CI/CD.

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

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

• GitLab Runner Fleeting plugin for GCP Compute Engine - Beta
• Implement graceful shutdown for Docker executor
• Dynamically create PVC volumes with storage classes for Kubernetes
• Override the container entrypoint through image.entrypoint in the Kubernetes executor

Bug Fixes:

• Pods keep restarting with a Liveness probe failed error after upgrade to GitLab Runner 16.5.0
• Debug terminal - variable contains content of file instead of file path
• Job execution pods in Kubernetes does not handle signals
• Services in GitLab Runner Docker executor using Podman do not start

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