gitlab-org/gitlab v16.11.0-ee

on GitLab

GitLab.com group Owners can now disable the creation and use of personal access tokens for any enterprise users in their groups. Due to the powerful privileges that can be associated with personal access tokens, some Owners may want to disable these tokens for security reasons.

This granular control gives options when it comes to balancing security and accessibility on GitLab.com.

Workload identity federation allows you to securely connect workloads between GitLab and Google Cloud without the use of service account keys. This improves security, because keys can potentially be long-lived credentials that expose a vector for attack. Keys also come with management overhead for creating, securing, and rotating.

Workload identity federation allows you to map IAM roles between GitLab and Google Cloud.

This feature is in Beta and is currently available only on GitLab.com.

Previously, creating GitLab Runners in Google Compute Engine required multiple context switches from GitLab and Google Cloud.

Now, you can easily provision GitLab Runners in Google Compute Engine with a terraform template from the GitLab Runner Infrastructure Toolkit and GitLab to deploy a GitLab runner and provision the Google Cloud infrastructure - without having to switch between multiple systems.

You use the GitLab container registry to view, push, and pull Docker and OCI images alongside your source code and pipelines. For many GitLab customers, this works great for container images during the test and build phases. But, it's common for organizations to publish their production images to a cloud provider, like Google.

Previously, to push images from GitLab to Google Artifact Registry, you had to create and maintain custom scripts to connect and deploy to Artifact Registry. This was inefficient and error prone. In addition, there was no way easy way to get a holistic view of all of your container images.

Now, you can leverage the new Google Artifact Management feature to easily connect your GitLab project to an Artifact Registry repository. Then you can use GitLab CI/CD pipelines to publish images to the Artifact Registry. You can also view images that have published to the Artifact Registry in GitLab by going to Deploy > Google Artifact Registry. To view details about an image, simply select an image.

This feature is in Beta and is currently available only on GitLab.com.

Policy scoping provides granular management and enforcement of policies. Across both merge request approval (scan result) policies and scan execution policies, this new feature enables security and compliance teams to scope policy enforcement to a compliance framework or to a set of included/excluded projects in a group.

While today all policies managed in a security policy project are enforced against all linked groups, subgroups, and projects, policy scoping will allow you to refine that enforcement policy by policy. This allows security and compliance teams to:

• More easily manage policies centrally across their organization, while still enforcing policies granularly.
• Get a better sense of how the controls they are implementing and enforcing in GitLab roll up to the compliance frameworks they've defined.
• View and manage which policies are linked to a compliance framework through the compliance center.
• Better organize and understand their security and compliance posture.

Configuration changes made to your GitLab Dedicated instance by tenant administrators using Switchboard will now generate email notifications when complete.

All users with access to view or edit your tenant in Switchboard will receive a notification for each change made.

As the compliance center becomes the battle station for compliance managers, you can now manage compliance frameworks, and also gain insight into controls that have been created through security policies and linked to a compliance framework.

Enforce security scanners to run in projects that are in-scope for your compliance, enforce two-person approval, or enable vulnerability management workflows through these extensive controls and then roll them up to a compliance framework, ensuring relevant projects within the framework are properly enforced by the control.

The security policy bot gives users context to understand when policies are enforced on their project, when evaluation is completed, and if there are any violations blocking an MR, with guidance to resolve them. We have now extended support in the bot comment to supply additional insight into why an MR may be blocked by a policy, with more granular feedback on how to resolve. Details provided by the comment include:

• Security findings that are specifically blocking the MR
• Out-of-policy licenses
• Policy errors that may default in a "fail closed" and blocking behavior
• Details regarding the pipelines that are being considered in the evaluation for security findings

With these extra details, you can now more quickly understand the state of your MR and self-serve to troubleshoot any issues.

In GitLab 16.9 and earlier, it was possible for a project to both inherit security policies from a parent group or subgroup and link to the same security policies project. The result was that policies were duplicated in the policies list.

This issue has been resolved and it is no longer possible to link to a security policies project from which policies are already inherited.

Users can access dependency graph information in CycloneDX SBOMs generated as a part of their dependency scanning report. Dependency graph information is available for the following package managers:

• NuGet
• Yarn 1.x
• sbt
• Conan

Dependency Scanning supports Yarn v4. This enhancement allows our analyzer to parse Yarn v4 lockfiles.

During the 16.11 release milestone we completed the following DAST improvements:

• Snip navigation paths to improve crawler performance, which reduced scan time by 20% according to our benchmark test. See the issue for more details.
• Optimize DAST reporting to reduce memory usage, which reduced runner memory spikes during DAST scans. See the issue for more details.

It is critical to understand how your users are engaging with your application in order to make data-driven decisions about future innovations and optimizations. Are you seeing an uptick in usage for your top business critical URLs, is there an unusual dip in monthly active users, are you seeing more customers engaging with a mobile Android device? By having the answers to questions like this and making them accessible to your engineering teams from the GitLab platform, your teams can stay in sync with how their development work is affecting user outcomes.

With GitLab's new Product Analytics feature, you can instrument your applications, collect key usage and adoption data about your users, and then display it inside GitLab. You can visualize data in dashboards, report on it, and filter it in a variety of different ways to find insights about your users. Your team can now quickly identify and respond to unexpected dips or spikes in customer usage that signify an issue, as well as celebrate the success of their recent releases.

To use Product Analytics, you will need a Kubernetes cluster to install this helm chart and instrument your application to send traffic to it. GitLab will then connect to the cluster to retrieve the data for visualization.

Product Analytics is now generally available, and this release includes a custom visualization designer. You can use it to explore your application event data, and build dashboards to help you understand your customers' usage and adoption patterns.

In the visualization designer, you can now ask GitLab Duo to build visualizations for you by entering plain text requests, for example "Show me the count of monthly active users in 2024" or "List the top urls this week.

GitLab Duo in Product Analytics is available as an Experimental feature.

You can help us mature this feature by providing feedback about your experience with GitLab Duo in the custom visualization designer in this feedback issue.

Webhook events for project and group access tokens are now available.

Previously, email was the only way to get notifications about expiring tokens. A webhook event, if triggered, will be triggered seven days before an access token expires.

To further improve the ability to use portfolio management features across the organization, you can now distinguish epics using colors on roadmaps and epic boards.

Quickly distinguish between group ownership, stage in a lifecycle, development towards maturity, or a number of other categorizations with this lightweight but versatile feature.

We introduced a more robust method for calculating durations between label events. This change accommodates scenarios where events occur multiple times, such as label changes in merge requests back and forth between development to review states. Previously, the duration was calculated as the total time elapsed between the first and last label event.

Now, the duration is calculated as cumulative time, meaning it now correctly represents only the time when an issue or merge request had a given label.

The GitLab integration with HashiCorp Vault has been expanded to support more types of secrets. You can now select a generic type of secrets engine, introduced in GitLab Runner 16.11. This generic engine supports HashiCorp Vault Artifactory Secrets Plugin and AWS secrets engine. Use this option to safely retrieve the secrets you need and use them in GitLab CI/CD pipelines!

Thanks so much to Ivo Ivanov for this great contribution!

We've redesigned the project overview page. Now you can find all of the project information and links in one sidebar rather than multiple areas.

GitLab Duo Chat is now generally available. As part of this release, we are also making these capabilities generally available:

• Code explanation helps developers and less technical users understand unfamiliar code faster
• Code refactoring enables developers to simplify and improve existing code
• Test generation automates repetitive tasks and helps teams catch bugs sooner

Users can access GitLab Duo Chat in the GitLab UI, in the Web IDE, in VS Code, or in JetBrains IDEs.

Learn more about this release of GitLab Duo Chat from this blog post.

Chat is currently freely accessible by all Ultimate and Premium users. Instance administrators, group owners, and project owners can choose to restrict Duo features from accessing and processing their data.

The GitLab Duo Chat is part of GitLab Duo Pro. To ease the transition for Chat beta users who have yet to purchase GitLab Duo Pro, Duo Chat will remain available to existing Premium and Ultimate customers (without the add-on) for a short period of time. We will announce when access will be restricted to Duo Pro subscribers at a later date.

Feel free to share your thoughts by clicking the feedback button in the chat or by creating an issue and mentioning GitLab Duo Chat. We’d love to hear from you!

• In GitLab 17.0, the minimum-supported version of PostgreSQL will become 14. In preparation for this change, in GitLab 16.11 we have changed the attempt_auto_pg_upgrade? setting to true, which will attempt to automatically upgrade the version of PostgreSQL to 14.

  This process is the same as for last time we bumped the minimum-supported PostgreSQL version.

Now it's easier to identify archived projects in project lists. From 16.11, archived projects display an Archived badge in the Archived tab of the group overview. This badge is also part of the project title on the project overview page.

An alert message clarifies that archived projects are read-only. This message is visible on all project pages to ensure that this context is not lost even when working on sub-pages of the archived project.

In addition, when deleting a group, the confirmation modal now lists the number of archived projects to prevent accidental deletions.

Because the heroku/buildpacks:20 image used by the Auto Build component of Auto DevOps was deprecated upstream, we are moving to the heroku/builder:20 image.

This breaking change arrives outside a GitLab major release to accommodate a breaking change upstream. The upgrade is unlikely to break your pipelines. As a temporary workaround, you can also manually configure the heroku/builder:20 image and skip the builder sunset errors.

Additionally, we're planning another major upgrade from heroku/builder:20 to heroku/builder:22 in GitLab 17.0.

The Admin Area users page has been improved.

Previously, tabs horizontally spanned across the top of the users list, making it difficult to navigate to the desired filter.

Now, filters have been combined into the search box, making it much easier to search and filter users.

Thank you Ivan Shtyrliaiev for your contribution!

You can now use the Applications API to renew application secrets. Previously, you had to use the UI to do this. Now you can use the API to rotate secrets programatically.

Thank you Phawin for your contribution!

Usernames can only include non-accented letters, digits, underscores (_), hyphens (-), and periods (.). Usernames must not start with a hyphen (-), or end in a period (.), .git, or .atom.

Username validation now more accurately states this criteria. This improved validation means that you are clearer on your options when choosing your username.

Thank you Justin Zeng for your contribution!

Previously, GitLab webhooks did not support custom headers. This meant you could not use them with systems that accept authentication tokens from headers with specific names.

With this release, you can add up to 20 custom headers when you create or edit a webhook. You can use these custom headers for authentication to external services.

With this feature and the custom webhook template introduced in GitLab 16.10, you can now fully design custom webhooks. You can configure your webhooks to:

• Post custom payloads.
• Add any required authentication headers.

Like secret tokens and URL variables, custom headers are reset when the target URL changes.

Thanks to Niklas for this community contribution!

Previously, you could test project hooks in the GitLab UI only. With this release, you can now trigger test hooks for specified projects by using the REST API.

Thanks to Phawin for this community contribution!

Previously, you could configure the GitLab for Slack app for one project at a time only. With this release, it's now possible to configure the integration for groups or instances and make changes to many projects at once.

This improvement brings the GitLab for Slack app closer to feature parity with the deprecated Slack notifications integration.

Until now, the maximum number of import jobs for:

• GitHub importer was 1000.
• Bitbucket Cloud and Bitbucket Server importers was 100.

These limits were hard-coded and couldn't be changed. These limits might have slowed down imports, because they might have been insufficient to allow the import jobs to be processed at the same rate they were enqueued.

In this release, we've moved the hard-coded limits to application settings. Although we are not increasing these limits on GitLab.com, administrators of self-managed GitLab instances can now configure the number of import jobs according to their needs.

We're thrilled to introduce autocomplete support for links to wiki pages in GitLab 16.11! With this new feature, linking to wiki pages from your epics and issues has never been easier - it's just a matter of a few keystrokes.

Gone are the days of having to copy and paste wiki page URLs into epic and issue comments. Now, simply navigate to any group or project with wiki pages, access an epic or issue, and use the autocomplete shortcut to seamlessly link to your wiki pages from the epic or issue!

In previous releases, for projects with a GitLab Pages site, it was difficult to find the site URL.

From GitLab 16.11, the right sidebar has a shortcut link to the site, so you can find the URL without needing to check the docs.

We are happy to announce the availability of GitLab Duo Chat in JetBrains IDEs.

As part of GitLab's AI offerings, Duo Chat further streamlines the developer experience by directly bringing an interactive chat window into any supported JetBrains IDE and the ability to explain code, write tests, and refactor existing code.

For a complete list of capabilities, see our Duo Chat documentation.

Across an organization it can be helpful to have the same templated response in issues, epics, or merge requests. These responses might include standard questions that need to be answered, responses to common problems, or maybe structure for merge request review comments.

Group comment templates enable you to create saved responses that you can apply in comment boxes around GitLab to speed up your workflow. This new addition to comment templates allows organizations to create and manage templates centrally, so all of their users benefit from the same templates.

To create a comment template, go to any comment box on GitLab and select Insert comment template > Manage group comment templates. After you create a comment template, it's available for all group members. Select the Insert comment template icon while making a comment, and your saved response will be applied.

We're really excited about this next iteration of comment templates and will also be adding project-level comment templates soon too. If you have any feedback, please leave it in issue 45120.

Sometimes after you notice a job fails, you might manually cancel the rest of the pipeline to save resources while you work on the issue causing the failure. With GitLab 16.11, you can now configure pipelines to be cancelled automatically when any job fails. With large pipelines that take a long time to run, especially with many long-running jobs that run in parallel, this can be an effective way to reduce resource usage and costs.

You can even configure a pipeline to immediately cancel if a downstream pipeline fails, which cancels the parent pipeline and all other downstream pipelines.

Special thanks to Marco for contributing to the feature!

Previously, you could use retry:when in addition to retry:max to configure how many times a job is retried when specific failures occur, like when a script fails.

With this release, you can now use retry:exit_codes to configure automatic retries of failed jobs based on specific script exit codes. You can use retry:exit_codes with retry:when and retry:max to fine-tune your pipeline's behavior according to your specific needs and improve your pipeline execution.

Thanks to Baptiste Lalanne for this community contribution!

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

Bug Fixes:

• Crash: fatal error: concurrent map read and map write
• FF_KUBERNETES_HONOR_ENTRYPOINT feature not working

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

By default, all generated artifacts from CI/CD jobs in a public pipeline are available for download by all users with access to the pipeline. However, there are cases where artifacts should never be downloaded, or only be accessible for download by team members with a higher access level.

So in this release, we've added the artifacts:access keyword. Now, users can control whether artifacts can be downloaded by all users with access to the pipeline, only users with the Developer role or higher, or no user at all.

The pipeline graph offers a comprehensive overview of your pipelines, showing job statuses, runtime updates, multi-project pipelines, and parent-child pipelines.

Today, we're excited to announce the release of the redesigned pipeline graph with enhanced aesthetics, grouped jobs visualization, improved mobile expirence and expanded downstream pipeline visibility within your existing view.

We'd greatly appreciate it if you could try it out and share your feedback through this dedicated issue.