GitLab 16.4 Release

GitLab 16.4 released with customizable roles and group-level dependency list

GitLab 16.4 released with Customizable Roles, Group/sub-group level dependency list, Access clusters locally using your GitLab user identity, Create workspaces for private projects and much more!

Today, we are excited to announce the release of GitLab 16.4 with Customizable Roles, Group/sub-group level dependency list, Access clusters locally using your GitLab user identity, Create workspaces for private projects and much more!

These are just a few highlights from the 100+ 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.4! 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.5 release kickoff video.

Note that our monthly release date will change to the third Thursday of every month starting with our 16.6 release.

GitLab MVP badge

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

Kik has been instrumental in designing and beginning the implementation of ActivityPub support in GitLab. His original deeply detailed architecture plan has been embraced by our product team and now lives as an epic in the GitLab project. The first MR implementing this code was recently merged, followed by a documentation addition.

As support for this large feature grows, Kik has shown himself to be a personification of the GitLab Values of Collaboration, Iteration and Transparency!

Kik has been a part of the GitLab community for many years, logging his first issue over 7 years ago. He’s chosen to become a bit more active over the last few months. When asked about his contributions, he stated:

If there is anything to highlight, it’s probably how enabling GitLab is, allowing to see its source code and tinker with it, while being welcoming to contributions, no matter how ambitious they are. :)

He has also chosen to help pioneer our sustainability efforts by choosing to have trees planted in his name instead of opting for swag. 🌳

Thank you, Kik, for choosing to help build GitLab and being a part of our amazing community! 🙌

16.4 Key improvements released in GitLab 16.4

Customizable roles

Customizable roles

Group Owners or administrators can now create and remove custom roles using the UI under the Roles and Permissions menu. To create a custom role, you add permissions on top of an existing base role. Currently, there are a limited number of permissions that can be added to a base role, including granular security permissions, the ability to approve merge requests, and view code. Each milestone, new permissions will be released that can then be added to existing permissions to create custom roles.

Create workspaces for private projects

Create workspaces for private projects

Previously, it was not possible to create a workspace for a private project. To clone a private project, you could only authenticate yourself after you created the workspace.

With GitLab 16.4, you can create a workspace for any public or private project. When you create a workspace, you get a personal access token to use with the workspace. With this token, you can clone private projects and perform Git operations without any additional configuration or authentication.

Create workspaces for private projects

Access clusters locally using your GitLab user identity

Access clusters locally using your GitLab user identity

Allowing developers access to Kubernetes clusters requires either developer cloud accounts or third-party authentication tools. This increases the complexity of cloud identity and access management. Now, you can grant developers access to Kubernetes clusters using only their GitLab identities and the agent for Kubernetes. Use traditional Kubernetes RBAC to manage authorizations within your cluster.

Together with the OIDC cloud authentication offering in GitLab pipelines, these features allow GitLab users to access cloud resources without dedicated cloud accounts without jeopardizing security and compliance.

In this first iteration of cluster access, you must manage your Kubernetes configuration manually. Epic 11455 proposes to simplify setup by extending the GitLab CLI with related commands.

Group/sub-group level dependency list

Group/sub-group level dependency list

When reviewing a list of dependencies, it is important to have an overall view. Managing dependencies at the project level is problematic for large organizations that want to audit their dependencies across all their projects. With this release, you can see all dependencies at the project or group level, including subgroups. This feature is now available by default.

Group/sub-group level dependency list

Vulnerability bulk status updates

Vulnerability bulk status updates

Some vulnerabilities need to be addressed in bulk. Whether they are false positives or no longer detected, it’s important to minimize the noise and triage vulnerabilities with ease. With this release you can bulk change the status and make a comment for multiple vulnerabilities from a group or project Vulnerability Report.

Vulnerability bulk status updates

Granular security permissions

Granular security permissions

Some organizations want to give their security teams the least amount of access necessary so they can adhere to the Principle of Least Privilege. Security teams should not have access to write code updates, but they must be able to approve merge requests, view vulnerabilities, and update a vulnerability’s status.

GitLab now allows users to create a custom role based on the access of the Reporter role, but with the added permissions of:

  • Viewing the dependency list (read_dependency).
  • Viewing the security dashboard and vulnerability report (read_vulnerability).
  • Approving a merge request (admin_merge_request).
  • Changing status of a vulnerability (admin_vulnerability).

We plan to remove the ability to change the status of a vulnerability from the Developer role for all tiers in 17.0, as noted in this deprecation entry. Feedback on this proposed change can be shared in issue 424688.

Fast-forward merge support for merge trains

Fast-forward merge support for merge trains

Fast-forward merge is a common and popular merge method which avoids merge commits, but requires more rebasing. Separately, Merge Trains are a powerful tool to help with some of the greater challenges related to frequently merging into the main branch. Unfortunately, before this release you could not use merge trains and fast-forward merge together.

In this release, self-managed admins can now enable both Fast-forward merge and merge trains in the same project. You can get all the benefits of merge trains, which ensure all your commits work together before merging, with the cleaner commit history of fast forward merges!

To enable the Fast-forward merge trains, locate the feature flag fast_forward_merge_trains_support, which has been disabled by default, and enable it.

Fast-forward merge support for merge trains

Set id_token globally and eliminate configuration for individual jobs

Set id_token globally and eliminate configuration for individual jobs

In GitLab 15.9 we announced the deprecation of older versions of JSON web tokens in favor of id_token. Unfortunately, jobs had to be modified individually to accommodate this change. To enable a smooth transition to id_token, beginning from GitLab 16.4, you can set id_tokens as a global default value in .gitlab-ci.yml. This feature automatically sets the id_token configuration for every job. Jobs that use OpenID Connect (OIDC) authentication no longer require you to set up a separate id_token.

Use id_token and OIDC to authenticate with third party services. The required aud sub-keyword is used to configure the aud claim for the JWT.

Set `id_token` globally and eliminate configuration for individual jobs

16.4 Other improvements in GitLab 16.4

Add webhooks for added or revoked emoji reactions

Add webhooks for added or revoked emoji reactions

To provide as many opportunities for automation and integration with third-party systems as possible, we have added support for creating webhooks that trigger when a user adds or revokes an emoji reaction.

You could use the new webhook, for example, to send an email when users react to issues or merge requests with emoji.

Expand configurable import limits available in application settings

Expand configurable import limits available in application settings

We recently turned a few hardcoded import limits into configurable application settings to allow self-managed GitLab administrators to adjust these limits according to their needs.

In this release, we’ve added the timeout for decompressing archived files as a configurable application setting.

This limit was hardcoded at 210 seconds. On GitLab.com, and for self-managed installations by default, we’ve set this limit to 210 seconds. Both self-managed GitLab and GitLab.com administrators can adjust this limit as needed.

GitLab Runner 16.4

GitLab Runner 16.4

We’re also releasing GitLab Runner 16.4 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.

macOS 13 (Ventura) image for SaaS runners on macOS

macOS 13 (Ventura) image for SaaS runners on macOS

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

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.

Custom email address for Service Desk

Custom email address for Service Desk

Service Desk is one of the most meaningful connections between your business and your customers. Now you can use your own custom email address to send and receive emails for Service Desk. With this change, it is much easier to maintain brand identity and instill customer confidence that they are communicating with the correct entity.

This feature is in Beta. We encourage users to try Beta features and provide feedback in the feedback issue.

Geo verifies object storage

Geo verifies object storage

Geo adds the ability to verify object storage when object storage replication is managed by GitLab. To protect your object storage data against corruption, Geo compares the file size between the primary and secondary sites. If Geo is part of your disaster recovery strategy, and you enable GitLab-managed object storage replication, this protects you against data loss. Additionally, it also reduces the need to copy data that may already be present on a secondary site. For example, when adding an old primary back as a secondary site.

Elasticsearch index integrity now generally available

Elasticsearch index integrity now generally available

With GitLab 16.4, Elasticsearch index integrity is generally available for all GitLab users. Index integrity helps detect and fix missing repository data. This feature is automatically used when code searches scoped to a group or project return no results.

Browser-based DAST active check 22.1 is enabled by default

Browser-based DAST active check 22.1 is enabled by default

Browser-based DAST active check 22.1 has been enabled by default. It replaces ZAP check 6, which has been disabled. Check 22.1 identifies “Improper limitation of a pathname to a restricted directory (Path traversal)”, which can be exploited by inserting a payload into a parameter on the URL endpoint, allowing for arbitrary files to be read.

Email notification when access expires

Email notification when access expires

A user will get an email notification seven days before their group or project access expires. This only applies if there is an access expiration date set. Previously, there were no notifications when access expired. Advance notice means you can contact your GitLab administrator to ensure continuous access.

Notifications for expiring access tokens

Notifications for expiring access tokens

Group and project access tokens are frequently used for automation. It is important that administrators and group Owners are notified when one of these tokens is close to expiry, so interruptions are avoided. Administrators and group Owners now receive a notification email when a token is seven days or less away from expiry.

Private registry support for Operational Container Scanning

Private registry support for Operational Container Scanning

Operational Container Scanning can now access and scan images from private container registries. OCS uses the image pull secrets to access private registry containers.

Create custom role name and description using API

Create custom role name and description using API

When creating a custom role, you can now use the member roles API to add a name (required) and description (optional). Any existing custom roles have been given the name Custom, and you can use the API to change a custom role’s name to a name of your choosing.

Trigger Slack notifications for group mentions

Trigger Slack notifications for group mentions

GitLab can send messages to Slack workspace channels for certain GitLab events. With this release, you can now trigger Slack notifications for group mentions in public and private contexts in:

  • Issue and merge request descriptions
  • Comments on issues, merge requests, and commits

Users with the Maintainer role can view runner details

Users with the Maintainer role can view runner details

Users with the Maintainer role for a group can now view details for group runners. Users with this role can view group runners to quickly determine which runners are available, or validate that automatically created runners were registered successfully to the group namespace.

Users with the Maintainer role can view runner details

Support for environment keyword in downstream pipelines

Support for environment keyword in downstream pipelines

If you need to trigger a downstream pipeline from a CI/CD pipeline job, you can use the trigger keyword. To enhance your deployment management, you can now specify an environment with the environment keyword when you use trigger. For example, you might trigger a downstream pipeline for the main branch on your /web-app project with environment name dev and a specified environment URL.

Previously, when you ran separate pipelines for CI and CD and used the trigger keyword to start the CD pipeline, specifying environment details was not possible. This made it hard to track deployments from your CI project. Adding support for environments simplifies deployment tracking across projects.

Geo supports unified URLs on Cloud Native Hybrid sites

Geo supports unified URLs on Cloud Native Hybrid sites

Geo now supports unified URLs on Cloud Native Hybrid sites, which means that Cloud Native Hybrid sites can share a single external URL with the primary site. This delivers a seamless GitLab UI and Git developer experience for your remote teams who can be automatically directed to the optimal Geo secondary site based on their location using a single common URL. With this update, unified URLs are now supported across all GitLab reference architectures.

Omnibus improvements

Omnibus improvements

Allow users to define branch exceptions to enforced security policies

Allow users to define branch exceptions to enforced security policies

Security policies enforce scanners to run in GitLab projects, as well as enforce MR checks/approvals to ensure security and compliance. With branch exceptions, you can more granularly enforce policies and exclude enforcement for any given branch that is out of scope. Should a developer create a development or test branch that is unintentionally affected by heavy-handed enforcement, they can work with security teams to exempt the branch within the security policy.

For scan execution policies, you can configure exceptions for the pipeline or schedule rule type. For scan result policies, you can specify branch exceptions for the scan_finding or license_finding rule type.

Allow users to define branch exceptions to enforced security policies

Dependency and License Scanning support for pnpm lockfile v6.1

Dependency and License Scanning support for pnpm lockfile v6.1

Thanks to a community contribution from Weyert de Boer, GitLab Dependency and License Scanning now support analyzing pnpm projects using v6.1 lockfile format.

Improved SAST vulnerability tracking

Improved SAST vulnerability tracking

GitLab SAST Advanced Vulnerability Tracking makes triage more efficient by keeping track of findings as code moves.

In GitLab 16.4, we’ve enabled Advanced Vulnerability Tracking for new languages and analyzers. In addition to its existing coverage, advanced tracking is now available for:

  • Java, in the SpotBugs-based SAST analyzer.
  • PHP, in the PHPCS Security Audit-based SAST analyzer.

This builds on previous expansions and improvements released in GitLab 16.3. We’re tracking further improvements in epic 5144.

These changes are included in updated versions of GitLab SAST analyzers. Your project’s vulnerability findings are updated with new tracking signatures after the project is scanned with the updated analyzers. You don’t have to take action to receive this update unless you’ve pinned SAST analyzers to a specific version.

Pipeline-specific CycloneDX SBOM exports

Pipeline-specific CycloneDX SBOM exports

We’ve added an API that allows you to download a CycloneDX SBOM, which lists all the components detected in a CI pipeline. This includes both application-level dependencies and system-level dependencies.

SAST analyzer updates

SAST analyzer updates

GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports. We published the following updates during the 16.4 release milestone:

  • Updated the KICS-based analyzer to version 1.7.7 of the KICS scanner. See the CHANGELOG for further details.
  • Updated the Sobelow-based analyzer to version 0.13.0 of the Sobelow scanner. We also updated the base image for the analyzer to Elixir 1.13 to improve compatibility with more recent Elixir releases. See the CHANGELOG
  • Updated the PMD Apex-based analyzer to version 6.55.0 of the PMD scanner. See the CHANGELOG for further details.
  • Changed the PHPCS Security Audit-based analyzer to remove the Security.Misc.IncludeMismatch rule. See the CHANGELOG for further details.
  • Updated the rules used in the Semgrep-based analyzer to fix rule errors, fix broken links in rule descriptions, and resolve conflicts between Java and Scala rules that had the same rule IDs. We also increased the maximum size of custom rule files to 10 MB. See the CHANGELOG for further details.

If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates. To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.

For previous changes, see last month’s updates.

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

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.

  • `postgres_exporter['per_table_stats']` configuration setting
  • Geo: Legacy replication details routes for designs and projects deprecated
  • Deprecate change vulnerability status from the Developer role
  • Internal container registry API tag deletion endpoint
  • The `ci_job_token_scope_enabled` projects API attribute is deprecated
  • 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.

    Other notable changes Other notable changes

    GitLab releases are moving to the third Thursday of the month

    GitLab releases are moving to the third Thursday of the month

    Starting with GitLab 16.6, which will be released on Nov. 16, 2023, our monthly release date will change from the 22nd of every month to the third Thursday of every month. This iteration in our release processes will ensure consistency and create more predictability for our customers in terms of the day of the week for the release while continuing our monthly pace of self-managed releases.

    Please see more information in our blog post.

    Important notes on upgrading to GitLab Important notes on upgrading to GitLab 16.4

    The introduction of verification of object storage files in Geo results in the detection of orphaned upload records and as a result, you may notice primary checksum failure for some uploads. The most likely cause of these failures is orphaned upload records. Orphaned upload records are a result of the parent record, such as Design Management or Vulnerability Report, having not been deleted together with the associated upload record leaving behind a parentless upload record. Prior to object storage verification being available, only orphaned upload records related to local storage were detected.

    In most cases, removing the upload record along with the associated file in object storage is safe and is not a data loss concern. It is recommended that each failure is investigated and confirmed to be obsolete before deletion.


    When upgrading to GitLab 16.4, any users who have not upgraded their security policy projects to use security bots must unlink and relink the security policy project from each group, sub-group, or project they have linked to refresh the connection.

    This can be configured using the Mutation.securityPolicyProjectUnassign GraphQL mutation and Mutation.securityPolicyProjectAssign GraphQL mutation or by utilizing the UI. Once completed, a security policy bot will be enabled in all projects where a security policy is enforced and will become the author of any scheduled scan execution pipelines.


    Before upgrading to GitLab 16.4, you need to make sure the Restricted visibility levels admin setting does not select levels that are set as default project and group visibility.

    This change is due to an added validation that is behind the on-by-default feature flag prevent_visibility_restriction.


    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