GitLab 16.6 Release

GitLab 16.6 released with GitLab Duo Chat available in Beta

GitLab 16.6 released with MR approvals as a compliance policy, improved forking, improved UI for CI/CD variable management, switchboard portal for GitLab Dedicated and much more!

Today, we are excited to announce the release of GitLab 16.6 with GitLab Duo Chat Available in Beta, MR approvals as a compliance policy, improved forking, improved UI for CI/CD variable management, and much more!

These are just a few highlights from the 25+ improvements in this release. Read on to check out all of the great updates below.

To the wider GitLab community, thank you for the 137 contributions you provided to GitLab 16.6! At GitLab, everyone can contribute and we couldn't have done it without you!

To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 16.7 release kickoff video.

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Joe Snyder

Joe Snyder was awarded GitLab’s 16.6 MVP for consistent contributions across GitLab, including recent merge requests to allow admins to filter runners by version.

Joe was nominated by Miguel Rincon, Staff Frontend Engineer at GitLab. Miguel recognized Joe’s efforts through several required rewrites due to GitLab’s evolving architecture and commented on Joe’s “thoughtful consideration of performance and usability.”

Pedro Pombeiro, Sr. Backend Engineer at GitLab, added that “Joe Snyder drove this change over the finish line after taking over from a former colleague, requiring learning all the context around the problem. He also proved very responsive and patient with our feedback in successive reviews.”

“Joe has been a pleasure to work with,” said Terri Chu, Staff Backend Engineer at GitLab. Terri highlighted Joe’s ongoing work on emails_enabled changes over the last (and previous) milestone.

Joe Snyder is a Senior R&D Engineer at Kitware and has been contributing to GitLab since 2021. Our many thanks to Joe for continuing to improve GitLab!

16.6 Key improvements released in GitLab 16.6

GitLab Duo Chat available in Beta

GitLab Duo Chat available in Beta

Everyone involved in the software development process can spend a significant amount of time familiarizing themselves with code, epics, issues, and lengthy discussion threads. You can often find yourself slowed down by routine tasks like writing summaries, documentation, tests, or even code. Having an expert at your side that can answer DevSecOps questions without judgment and address follow-ups could help you accelerate the software development process.

GitLab Duo Chat aims to actively address these pain points and accelerate your workflows. Its capabilities include:

  • Explain or summarize issues, epics, and code.
  • Answer specific questions about these artifacts like “Collect all the arguments raised in comments regarding the solution proposed in this issue.”
  • Generate code or content based the information in these artifacts. For instance, “Can you write documentation for this code?”
  • Or simply get you started from scratch like “Create a .gitlab-ci.yml configuration file for testing and building a Ruby on Rails application in a GitLab CI/CD pipeline.”
  • Answer all your DevSecOps related question, whether you are beginner or an expert. For example, “How can I set up Dynamic Application Security Testing for a REST API?”
  • Answer follow-up questions so you can iteratively work through all the above scenarios.

GitLab Duo Chat is available on GitLab.com as a Beta feature. It is also integrated into our Web IDE and GitLab Workflow extension for VS Code as Experimental features.

You can also help us mature these features by providing feedback about your experiences with Duo Chat, either within the product or via our feedback issue.

Automatic claims of enterprise users

Automatic claims of enterprise users

When a GitLab.com user’s primary email address matches an existing verified domain, the user is automatically claimed as an enterprise user. This gives the group Owner more user management controls and visibility into the user’s account. After a user becomes an enterprise user, they can only change their primary email to an email their organization owns as per its verified domains.

Automatic claims of enterprise users

Minimal forking - only include the default branch

Minimal forking - only include the default branch

In previous versions of GitLab, when forking a repository, the fork always included all branches within the repository. Now you can create a fork with only the default branch, reducing complexity and storage space. Create minimal forks if you don’t need the changes that are currently being worked on in other branches.

The default method of forking will not change and continue to include all branches within the repository. The new option shows which branch is the default, so that you are aware of exactly which branch will be included in the new fork.

Minimal forking - only include the default branch

Allow users to enforce MR approvals as a compliance policy

Allow users to enforce MR approvals as a compliance policy

There is an increasing scrutiny on code changes that can potentially land in production applications and open businesses up to compliance risk and security vulnerability. With scan result policies, you can ensure unilateral changes cannot be made by enforcing two person approval on all merge requests.

Scan results policies have a new option to target Any merge request which can be paired with defining role-based approvers to ensure each MR for the defined branches require approval by two (or more) users with a given role (Owner, Maintainer, or Developer).

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

Allow users to enforce MR approvals as a compliance policy

Switchboard portal for GitLab Dedicated is now generally available

Switchboard portal for GitLab Dedicated is now generally available

Switchboard, a new self-service portal, is now available for customers and team members to onboard, configure and maintain their GitLab Dedicated instances.

Using Switchboard, you can now make some configuration changes to your GitLab Dedicated instance. This functionality will expand in future releases.

Switchboard portal for GitLab Dedicated is now generally available

CI/CD components Beta release

CI/CD components Beta release

In GitLab 16.1, we announced the release of an exciting experimental feature called CI/CD components. The component is a pipeline building block that can be listed in the upcoming CI/CD catalog.

Today we are excited to announce the Beta availability of CI/CD components. With this release, we have also improved the components folder structure from the initial experimental version. If you are already testing the experimental version of CI/CD components, it’s essential to migrate to the new folder structure. You can see some examples here. The old folder structure is deprecated and we plan to remove it within the next couple of releases.

If you try out CI/CD components, you are also welcome to try the new CI/CD catalog, currently available as an experimental feature. You can search the Global CI/CD catalog for components that others have created and published for public use. Additionally, if you create your own components, you can choose to publish them in the catalog too!

CI/CD components Beta release

Improved UI for CI/CD variable management

Improved UI for CI/CD variable management

CI/CD variables are a fundamental part of GitLab CI/CD, and we felt that we could offer a better experience for working with variables from the settings UI. So in this release we’ve updated the UI to use a new drawer that improves the flow of adding and editing CI/CD variables.

For example, the masking validation used to only happen when you tried to save the CI/CD variable, and if it failed you’d have to restart from scratch. But now with the new drawer, you get real time validation so you can adjust on the fly without needed to redo anything!

Your feedback for this change is always valued and appreciated.

Improved UI for CI/CD variable management

Runner Fleet Dashboard - Starter metrics (Beta)

Runner Fleet Dashboard - Starter metrics (Beta)

Operators of self-managed runner fleets need observability and the ability to quickly answer critical questions about their runner fleet infrastructure at a glance. Now, with the Runner Fleet Dashboard - Admin View (Beta), you have actionable insights to help you quickly answer critical fleet management and developer experience questions, starting with instance runners. These include answers to questions like which runners have errors, the performance of the runner queues for CI job execution, and which runners are most actively used. Ultimate customers can enable this feature independently, but are encouraged to participate in the early adopter’s program.

Runner Fleet Dashboard - Starter metrics (Beta)

16.6 Other improvements in GitLab 16.6

Comprehensive list of items that failed to be imported

Comprehensive list of items that failed to be imported

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.

Prevent duplicate NuGet packages

Prevent duplicate NuGet packages

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.

Connect to Kubernetes clusters with the GitLab CLI

Connect to Kubernetes clusters with the GitLab CLI

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.

GitLab Silent Mode

GitLab Silent Mode

When GitLab Silent Mode is enabled, it blocks all major outbound traffic such as notification emails, integrations, webhooks, and mirroring from a GitLab instance. This allows you to perform testing against a GitLab site without generating traffic towards users and other integrations. You can use Silent Mode to test a restored backup or a promoted Geo DR site without impacting your primary GitLab site or your end users.

Allow compliance teams to prevent pushing and force pushing into protected branches

Allow compliance teams to prevent pushing and force pushing into protected branches

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.

Allow compliance teams to prevent pushing and force pushing into protected branches

Container Scanning: Exclude findings which won’t be fixed

Container Scanning: Exclude findings which won’t be fixed

Container scanning results may include findings which the vendor has evaluated and decided to not fix. To allow you to focus on actionable findings, you can now exclude such findings. For configuration options please refer to the GitLab documentation.

Group-level audit event streaming to AWS S3

Group-level audit event streaming to AWS S3

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.

Include CVSS Vectors in the vulnerability report export

Include CVSS Vectors in the vulnerability report export

When you export information from the vulnerability report, the CVSS Vector information is now included. This additional data helps you analyze and triage vulnerabilities outside GitLab.

Consistent navigation experience for all users

Consistent navigation experience for all users

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

macOS 14 (Sonoma) and Xcode 15 image support

macOS 14 (Sonoma) and Xcode 15 image support

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.

Upload packages to the Maven repository with basic HTTP authentication

Upload packages to the Maven repository with basic HTTP authentication

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.

Real-time Kubernetes status updates in the GitLab UI

Real-time Kubernetes status updates in the GitLab UI

In GitLab 16.6, you can use the cluster UI integration on your environment page to determine the status of currently running applications without leaving GitLab. Previously, the status was updated by a one-time request when the UI loaded, which made tracking deployment progress unwieldy. The current version of GitLab upgrades the underlying connection to use the Kubernetes watch API for the Flux reconciliation and Pod statuses, and provides near real-time updates of the cluster state in the GitLab UI.

Hide archived projects in search results by default

Hide archived projects in search results by default

Previously, users saw many archived projects in their project search results. This was problematic, especially when archived projects took up many of the top results. We now filter out archived projects by default, and users can select Include archived to see all projects.

Private group names are hidden from unauthorized users

Private group names are hidden from unauthorized users

Previously, the names of private groups were visible to all users when accessing the Groups tab of a project’s or group’s members page. To enhance security, we are now masking private groups’ name and source from users who are not members of the shared group, shared project, or invited group. Instead, this information will be displayed as Private.

Private group names are hidden from unauthorized users

Added support for SBT projects using Java 21

Added support for SBT projects using Java 21

Dependency Scanning and License Scanning now support SBT projects using Java 21.

Changes to the vulnerability report’s Tool filter

Changes to the vulnerability report’s Tool filter

Previously, the vulnerability report allowed you to filter by a static list of GitLab-supported tool types, followed by a dynamic list of custom scanners. With this release, you can now select tool type grouped by analyzer.

Changes to the vulnerability report's Tool filter

DAST analyzer updates

DAST analyzer updates

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.

Improved handling of unresponsive external status checks

Improved handling of unresponsive external status checks

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.

Service accounts have optional expiry dates

Service accounts have optional expiry dates

GitLab administrators and group Owners can choose if they want to enforce an expiry date for service accounts. Previously, service account tokens had to expire within a year, in line with personal, project, and group access token expiration limits. This allows administrators and group Owners to choose the balance between security and ease of use that best aligns with their goals.

Bug fixes, performance improvements, and UI improvements

Bug fixes, performance improvements, and UI improvements

At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance UI. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.

Click the links below to see all the bug fixes, performance enhancements, and UI improvements we’ve delivered in 16.6.

Deprecations Deprecations

New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

  • Proxy-based DAST deprecated
  • Breaking change to the Maven repository group permissions
  • GraphQL: deprecate support for `canDestroy` and `canDelete`
  • The GitHub importer Rake task
  • File type variable expansion fixed in downstream pipelines
  • Legacy Geo Prometheus metrics
  • Container registry support for the Swift and OSS storage drivers
  • Removals and breaking changes Removals and breaking changes

    The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

    • Job token allowlist covers public and internal projects
    • Other notable changes Other notable changes

      GitLab continues to expand the Registration Features Program

      GitLab continues to expand the Registration Features Program

      Building on what we started in 14.1 and beyond, in 16.5 and 16.6 GitLab has introduced an additional 10 features to the Registration Features Program:

      1. Group wikis - GitLab 16.5 and later
      2. Issue analytics - GitLab 16.5 and later
      3. Custom Text in Emails - GitLab 16.5 and later
      4. Contribution analytics - GitLab 16.5 and later
      5. Group file templates - GitLab 16.6 and later
      6. Group webhooks - GitLab 16.6 and later
      7. Service Level Agreement countdown timer - GitLab 16.6 and later
      8. Lock project membership to group - GitLab 16.6 and later
      9. Users and permissions report - GitLab 16.6 and later
      10. Advanced search - GitLab 16.6 and later

      If you are interested in participating as a free self-managed user running GitLab Enterprise Edition, you can read about how to turn on Service Ping here.

      Changelog Changelog

      Please check out the changelog to see all the named changes:

      Installing Installing

      If you are setting up a new GitLab installation please see the download GitLab page.

      Updating Updating

      Check out our update page.

      Questions? Questions?

      We'd love to hear your thoughts! Visit the GitLab Forum and let us know if you have questions about the release.

      GitLab Subscription Plans GitLab Subscription Plans

      • Free

        Free-forever features for individual users

      • Premium

        Enhance team productivity and coordination

      • Ultimate

        Organization wide security, compliance, and planning

      Try all GitLab features - free for 30 days

      We want to hear from you

      Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

      Share your feedback

      Take GitLab for a spin

      See what your team could do with The DevSecOps Platform.

      Get free trial

      Have a question? We're here to help.

      Talk to an expert
      Edit this page View source