GitLab 16.7 Release

GitLab 16.7 released with general availability of GitLab Duo Code Suggestions and CI/CD Catalog in Beta

GitLab 16.7 released with general availability of GitLab Duo Code Suggestions, CI/CD Catalog in Beta, new drill-down view from Insights report charts, SAST results in MR changes view, and much more!

Today, we are excited to announce the release of GitLab 16.7 with general availability of GitLab Duo Code Suggestions, CI/CD Catalog in Beta, new drill-down view from Insights report charts, SAST findings in MR changes view, and much more!

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

To the wider GitLab community, thank you for the 186 contributions you provided to GitLab 16.7! 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.8 release kickoff video.

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is jointly awarded to Muhammed Ali and Niklas van Schrick

As we continue to focus on growing our wider community, we are incredibly happy to see both MVPs nominated by members of the Core team.

Muhammed was nominated for adding support for specifying platform when using Docker images with GitLab Runner. This contribution took 9 months of collaboration and showed Muhammed’s commitment and perseverance when a bug required a follow-up. This solved a popular two-year-old issue. “Great shoutout to the GitLab Runner team” Muhammed said, “for supporting me on bringing a long awaited feature to fruition”. Muhammed is an Automation Engineer at Airtime Rewards, working mainly with Terraform and promoting CI/CD and automation practices within the engineering teams.

Niklas was nominated for his continued contributions and support in many different forms. Today marks exactly 1 year since his last MVP award. Niklas tackles daunting work which proves challenging even for GitLab team members and plays a huge part in maintaining our wider community contributors. Read more in the nomination issue.

Thank you Muhammed and Niklas! 🙌

16.7 Key improvements released in GitLab 16.7

GitLab Duo Code Suggestions is generally available

GitLab Duo Code Suggestions is generally available

GitLab Duo Code Suggestions is now generally available!

GitLab Duo Code Suggestions helps teams create software faster and more efficiently, by completing lines of code and defining and generating logic for functions.

Code Suggestions is built with privacy as a critical foundation. Private, non-public customer code stored in GitLab is not used as training data. Learn about data usage when using Code Suggestions.

In the general release, we’ve made Code Suggestions available across several IDEs. Code Suggestions is also now more intuitive and responsive.

GitLab Duo Code Suggestions is free to try subject to the GitLab Testing Agreement until February 15, 2024. Starting today, you can buy Code Suggestions as an add-on to GitLab subscriptions for an introductory price of $9 USD per user/per month. Please contact us to get started with Code Suggestions.

Use GitLab pages without a wildcard DNS

Use GitLab pages without a wildcard DNS

Previously, to create a GitLab Pages project, you needed a domain formatted like name.example.io or name.pages.example.io. This requirement meant you had to set up wildcard DNS records and SSL/TLS certificates. In GitLab 16.7, you can set up a GitLab Pages project without a DNS wildcard. This feature is an experiment.

Removing the requirement for wildcard certificates eases administrative overhead associated with GitLab pages. Some customers can’t use GitLab Pages because of organizational restrictions on wildcard DNS records or certificates.

We welcome feedback related to this feature in issue 434372.

New drill-down view from Insights report charts

New drill-down view from Insights report charts

With the Insights report you can analyze patterns over time using customizable charts. The new drill-down capability added to the “Bugs created by priority” and “Bugs created by severity” Insights reports allows you to drill down on the Issue analytics report for deeper analysis.

We plan to include this capability in the other Insight reports as a custom option in a later version.

New drill-down view from Insights report charts

SAST results in MR changes view

SAST results in MR changes view

SAST findings now appear in the merge request Changes view. This makes it easier to see, understand, and fix potential weaknesses during the code review process.

Lines containing SAST issues are marked by a symbol beside the gutter. Select the symbol to see the list of issues, then select an issue to see its details.

We’ve enabled this feature on GitLab.com. We plan to enable the feature flag by default for Self-Managed instances in GitLab 16.8.

CI/CD Catalog - Beta release

CI/CD Catalog - Beta release

GitLab 16.7 sees the Beta release of the CI/CD catalog! The catalog is where you can search for CI/CD components maintained by you, your organization, or the public community. This is the place where DevOps engineers come together to create, contribute, and share reusable pipeline configurations.

Unlike other methods of reusing CI/CD configuration, CI/CD components published in the catalog have an improved experience, and are easily added to your pipeline. We invite you to start testing this new and exciting feature! You can try out components that others have created and shared in the catalog, or create your own components and share them with everyone.

While this is our initial beta release of the feature, we continue to work on making the experience even better. Our goal is to make the CI/CD catalog a fundamental part of the GitLab CI/CD experience.

16.7 Other improvements in GitLab 16.7

Access the Admin Area from the left sidebar

Access the Admin Area from the left sidebar

Administrators can now access the Admin Area in one step, by using a link at the bottom of the left sidebar. Previously, you had to select Search or go to and then select Admin Area. This change should save you time when accessing the Admin Area.

Access the Admin Area from the left sidebar

Customize time format for display

Customize time format for display

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.

Filter by predefined date ranges in Value Stream Analytics

Filter by predefined date ranges in Value Stream Analytics

The value stream analytics report now has a set of filter options for data in the last 30, 60, 90, or 180 days. These new filter options simplify the date selection process, making it more efficient and user-friendly to understand where time is spent during the development lifecycle.

Filter by predefined date ranges in Value Stream Analytics

Add custom emoji to groups

Add custom emoji to groups

Who doesn’t love a good emoji to really express yourself? When commenting on items across GitLab, you’ve used our default set of emoji to add reactions, but sometimes those emoji just weren’t enough to express your emotions. Groups can now add custom emoji to use across their projects. Custom emoji allow you to express your true feelings and communicate more clearly with the rest of your team. We can’t wait to see how you’ll react next.

Add custom emoji to groups

Define a network policy with egress rules

Define a network policy with egress rules

In GitLab 16.7, you can now define a network policy with egress rules when you configure the GitLab agent for Kubernetes to support Workspaces. Use this feature for your self-hosted installation where the GitLab instance resolves to a private IP or when a workspace must access a cloud resource on a private IP range.

GitLab Runner 16.7

GitLab Runner 16.7

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:

Bug Fixes:

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

Improved ability to keep the latest job artifacts

Improved ability to keep the latest job artifacts

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.

List repository tags with new Container Registry API

List repository tags with new Container Registry API

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.

Beta support for OpenTofu

Beta support for OpenTofu

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.

Backups supports alternate compression libraries

Backups supports alternate compression libraries

You can now override the default single-threaded gzip compression library with an alternate compression library of your choice for backups using the COMPRESS_CMD and DECOMPRESS_CMD commands. This allows you to leverage parallel compression libraries to speed up the compression stage of the backup by using the power of modern multi-core processors. The commands include support for passing options to the compression library allowing you to adjust parameters such as compression levels and speed.

Group descriptions extended to 500 characters

Group descriptions extended to 500 characters

Group descriptions can now contain up to 500 characters. If you try to save a group description with more than 500 characters, a warning message appears stating that the description is too long. Thanks to @freznicek for this community contribution!

Search bar more prominent on the search results page

Search bar more prominent on the search results page

The search bar is now more prominent on the search results page. To increase the search bar visibility, the group and project filters have been moved to the left sidebar.

Search bar more prominent on the search results page

DAST authentication now supports multi-step login forms

DAST authentication now supports multi-step login forms

The new DAST_AFTER_LOGIN_ACTIONS variable enables you to provide a list of actions to be executed after login. This allows for multi step login interactions, for example Azure AD’s “Keep Me Signed In” workflow.

Enforce variables in Scan Execution Policies with the highest precedence

Enforce variables in Scan Execution Policies with the highest precedence

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.

Support for Continuous Vulnerability Scanning for Dependency Scanning

Support for Continuous Vulnerability Scanning for Dependency Scanning

Continuous Vulnerability Scanning is now Generally Available. With CVS enabled, your projects are automatically scanned when advisories are added to the GitLab Advisory Database. If new dependency-related vulnerabilities are identified, vulnerabilities are created automatically.

Use the UI to assign users to custom roles

Use the UI to assign users to custom roles

You can now use the UI to assign a custom role to a new user, or change an existing user’s role to a custom role. You can do this in any part of the UI where you can currently assign or change a user’s role. Previously, you could only do this through the API.

Comprehensive results of imports by direct transfer

Comprehensive results of imports by direct transfer

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 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.

Remove hardcoded time limit for migrations to complete

Remove hardcoded time limit for migrations to complete

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.

Improvements to rich text editor

Improvements to rich text editor

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.

Complex merge request dependency chains now supported

Complex merge request dependency chains now supported

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.

Notify me when any merge request needs approval

Notify me when any merge request needs approval

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.

Notify me when any merge request needs approval

GitLab Runner supports SLSA v1.0 statement

GitLab Runner supports SLSA v1.0 statement

Runners can now generate provenance metadata with a statement that adheres to SLSA 1.0. To enable SLSA 1.0, set the SLSA_PROVENANCE_SCHEMA_VERSION=v1 variable in the .gitlab-ci.yml file. The SLSA version 1.0 statement is planned to become the default version in GitLab 17.0.

artifacts:public CI/CD keyword now generally available

artifacts:public CI/CD keyword now generally available

Previously, the artifacts:public keyword was only available as a default disabled feature for self-managed instances. Now in GitLab 16.7 we’ve made the artifacts:public keyword generally available for all users. You can now use the artifacts:public keyword in CI/CD configuration files to control whether job artifacts should be publicly accessible.

Rename projects with container images in the container registry on GitLab.com

Rename projects with container images in the container registry on GitLab.com

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!

Reopen Service Desk issues when an external participant comments

Reopen Service Desk issues when an external participant comments

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.

Add a Mastodon handle to your User Profile

Add a Mastodon handle to your User Profile

You can now list your Mastodon handle on the User Profile. With this enhancement we are now supporting a fediverse social network, which will help in advancing ActivityPub for GitLab.

In GitLab 16.7, issues with code have become more discoverable. With advanced search, you can now find issues that contain code snippets and logs in their descriptions.

Custom time period for access tokens rotation

Custom time period for access tokens rotation

You can now optionally input a new parameter, expires_at, when rotating an access token. This allows you to create a custom expiry date for the token. Previously, each rotation extended the expiration one week from the previous expiry date. This new option provides flexibility in rotation interval.

DAST vulnerability check updates

DAST vulnerability check updates

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.

SAML attribute statements support Microsoft SAML attribute format

SAML attribute statements support Microsoft SAML attribute format

SAML attribute statements now support the Microsoft SAML attribute format, which is in URL form. Previously, self-managed instance administrators had to manually configure attribute statements, and GitLab.com group owners had to add custom attributes to their SAML responses. This change allows both self-managed GitLab and GitLab.com to work with Microsoft without any manual configuration.

Updated SAST rules to reduce false-positive results

Updated SAST rules to reduce false-positive results

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.

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.7.

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.

  • JWT `/-/jwks` instance endpoint is deprecated
  • List repository directories Rake task
  • Dependency Proxy: Access tokens to have additional scope checks
  • 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.

    • Shimo integration
    • `user_email_lookup_limit` API field
    • Other notable changes Other notable changes

      GitLab continues to expand the Registration Features Program

      GitLab continues to expand the Registration Features Program

      In GitLab 16.7, GitLab continued to expand the Registration Features Program by adding five more features to bring the total to 24:

      1. Сross-project pipelines with artifacts dependencies
      2. Feature flag related issues
      3. Merged results pipelines
      4. CI/CD for external repositories
      5. CI/CD for GitHub

      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.

      Important notes on upgrading to GitLab Important notes on upgrading to GitLab 16.7

      From Gitlab 16.7, Ruby 3.1 is required. Administrators installing from source must have Ruby 3.1 as a minimum version when upgrading to GitLab 16.7 or later. Otherwise, no action is required by users at this time. This change is necessary as Ruby 3.0 will reach its end-of-life and will no longer receive official updates or support. GitLab will continue our policy of backporting security fixes to the previous two monthly releases in addition to the current stable release.


      New installations of GitLab will default to Postgres 14 in GitLab 16.7. GitLab will still support Postgres 13 until the 17.0 major release. This change doesn’t affect existing installations.


      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