GitLab 17.4 Release

Idempotency keys for webhook requests

Idempotency keys for webhook requests

From this release, we support an idempotency key in the headers of webhook requests. An idempotency key is a unique ID that remains consistent across webhook retries, which allows webhook clients to detect retries. Use the Idempotency-Key header to ensure the idempotency of webhook effects on integrations.

Thanks to Van for this community contribution!

Resizable wiki sidebar

Resizable wiki sidebar

You can now adjust the wiki sidebar to see longer page titles, improving the overall discoverability of content. As wiki content grows, having a resizable sidebar helps manage and browse through complex hierarchies or extensive lists of pages more efficiently.

CI/CD component for code intelligence

CI/CD component for code intelligence

Code intelligence in GitLab provides code navigation features when browsing a repository. Getting started with code navigation is often complicated, as you must configure a CI/CD job. This job can require custom scripting to provide the correct output and artifacts.

GitLab now supports an official Code intelligence CI/CD component for easier setup. Add this component to your project by following the instructions for using a component. This greatly simplifies adopting code intelligence in GitLab.

Currently, the component supports these languages:

• Go version 1.21 or later.
• TypeScript or JavaScript.

We’ll continue to evaluate available SCIP indexers as we look to broaden language support for the new component. If you’re interested in adding support for a language, please open a merge request in the code intelligence component project.

GitLab Runner 17.4

GitLab Runner 17.4

We’re also releasing GitLab Runner 17.4 today! GitLab Runner is the highly-scalable build agent that runs your CI/CD jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What’s new:

• GitLab Runner fleeting plugin for Azure compute (GA)

Bug Fixes:

• The entire step_script contents appear in the job log’s after_script section when a Kubernetes executor job is cancelled before completion

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

Non-deployment jobs to protected environments aren’t turned into manual jobs

Non-deployment jobs to protected environments aren’t turned into manual jobs

Due to an implementation issue, the action: prepare, action: verify, and action: access jobs become manual jobs when they run against a protected environment. These jobs require manual interaction to run, although they don’t require any additional approvals.

Issue 390025 proposes to fix the implementation, so these jobs won’t be turned into manual jobs. After this proposed change, to keep the current behavior, you will need to explicitly set the jobs to manual.

For now, you can change to the new implementation now by enabling the prevent_blocking_non_deployment_jobs feature flag.

Any proposed breaking changes are intended to differentiate the behavior of the environment.action: prepare | verify | access values. The environment.action: access keyword will remain the closest to its current behavior.

To prevent future compatibility issues, you should review your use of these keywords now. You can learn more about these proposed changes in the following issues:

• Issue 437132
• Issue 437133
• Issue 437142

Omnibus improvements

Omnibus improvements

GitLab 17.4 includes PostgreSQL 16 by default for fresh installations of GitLab.

GitLab 17.5 will include OpenSSL V3. This will affect Omnibus instances with external integration setup’s that do not meet the minimum requirements of TLS 1.2 or above for outbound connections, along with at least 112-bit encryption for TLS certificates. Please review our OpenSSL upgrade documentation for more information or if your are unsure if your instance will be affected.

List groups invited to a group or project using the Groups or Projects API

List groups invited to a group or project using the Groups or Projects API

We added new endpoints to the Groups API and Projects API to retrieve the groups that have been invited to a group or project. This functionality is available only on the Members page of a group or project. We hope that this addition will make it easier to automate membership management for your groups and projects. The endpoints are rate-limited to 60 requests per minute per user.

GitLab Duo seat assignment email

GitLab Duo seat assignment email

Users on self-managed instances will now receive an email when they are assigned a GitLab Duo seat. Previously, you wouldn’t know you were assigned a seat unless someone told you, or you noticed new functionality in the GitLab UI.

To disable this email, an administrator can disable the duo_seat_assignment_email_for_sm feature flag.

Grant read access to pipeline execution YAML files in projects linked to security policies

Grant read access to pipeline execution YAML files in projects linked to security policies

In GitLab 17.4, we added a setting to security policies you can use to grant read access to pipeline-execution.yml files for all linked projects. This setting gives you more flexibility to enable users, bots, or tokens that enforce pipeline execution globally across projects. For example, you can ensure a group or project access tokens can read security policy configurations in order to trigger pipelines during pipeline execution. You still can’t view the security policy project repository or YAML directly. The configuration is used only during pipeline creation.

To configure the setting, go to the security policy project you want to share. Select Settings > General > Visibility, project features, permissions, scroll to Pipeline execution policies, and enable the Grant access to this repository for projects linked to it as the security policy project source for security policies toggle.

Search by multiple compliance frameworks

Search by multiple compliance frameworks

In GitLab 17.3, we provided users with the ability to add multiple compliance frameworks to a project.

Now you can search by multiple compliance frameworks, which makes it easier to search for projects that have multiple compliance frameworks attached to them.

Support for ingesting CycloneDX 1.6 SBOMs

Support for ingesting CycloneDX 1.6 SBOMs

GitLab 15.3 added support for ingesting CycloneDX SBOMs.

In GitLab 17.4 we have added support for ingesting CycloneDX version 1.6 SBOMs.

Fields relating to hardware (HBOM), services (SaaSBOM), and AI/ML models (AI/ML-BOM) are not currently supported. SBOMs that contain data relating to these BOMs will be processed, but the data will not be analyzed or presented to users. Support for these other BOM-types is being tracked in this epic.

Resend failed webhook requests with the API

Resend failed webhook requests with the API

Previously, GitLab provided the ability to resend webhook requests only in the UI, which was inefficient if many requests failed.

So that you can handle failed webhook requests programmatically, in this release thanks to a community contribution, we added API endpoints for resending them:

• Project webhook requests
• Group webhook requests (Premium and Ultimate tier only)

You can now:

1. Get a list of project hook or group hook events.
2. Filter the list to see failures.
3. Use the id of any event to resend it.

Thanks to Phawin for this community contribution!

Authenticate with OAuth for GitLab Duo in JetBrains IDEs

Authenticate with OAuth for GitLab Duo in JetBrains IDEs

Our GitLab Duo plugin for JetBrains now offers a more secure and streamlined onboarding process. Sign in quickly and securely with OAuth. It integrates seamlessly with your existing workflow, with no personal access token required!

Linked files in merge request show first

Linked files in merge request show first

When you share a link to a specific file in a merge request, it’s often because you want the person to look at something within that file. Merge requests previously needed to load all of the files before scrolling to the specific position you’ve referenced. Linking directly to a file is a great way to improve the speed of collaboration in merge requests:

1. Find the file you want to show first. Right-click the name of the file to copy the link to it.
2. When you visit that link, your chosen file is shown at the top of the list. The file browser shows a link icon next to the file name.

Feedback about linked files can be left in issue 439582.

JaCoCo support for test coverage visualization available in beta

JaCoCo support for test coverage visualization available in beta

You can now use JaCoCo coverage reports, a popular standard for coverage calculation, inside your merge requests. The feature is available as beta, but ready for testing by anyone who wants to use JaCoCo coverage reports right away. If you have any feedback, feel free to contribute to the feedback issue.

Trigger a Flux reconciliation from the cluster UI

Trigger a Flux reconciliation from the cluster UI

Although you can configure Flux to trigger reconciliations at specified intervals, there are situations where you might want an immediate reconciliation. In past releases, you could trigger the reconciliation from a CI/CD pipeline or from the command line. In GitLab 17.4, you can now trigger a reconciliation from a dashboard for Kubernetes with no additional configuration.

To trigger a reconciliation, go to a configured dashboard and select the Flux status badge.

Improved source display for group and project members

Improved source display for group and project members

We have simplified the display of the source column on the Members page for groups and projects. Direct members are still indicated as Direct member. Inherited members are now listed as Inherited from followed by the group name. Members that were added by inviting a group to the group or project are listed as Invited group followed by the group name. For members that inherited from an invited group that was added to a parent group, we now display the last step to keep the display actionable for users managing membership.

Restrict group access by domain with the Groups API

Restrict group access by domain with the Groups API

Previously, you could only add domain restrictions at the group level in the UI. Now, you can also do this by using the new allowed_email_domains_list attribute in the Groups API.

Automatic cleanup for removed SAST analyzers

Automatic cleanup for removed SAST analyzers

In GitLab 17.0, 16.0, and 15.4, we streamlined GitLab SAST so it uses fewer separate analyzers to scan your code for vulnerabilities.

Now, after you upgrade to GitLab 17.3.1 or later, a one-time data migration will automatically resolve leftover vulnerabilities from the analyzers that have reached End of Support. This helps clean up your Vulnerability Report so you can focus on the vulnerabilities that are still detected by the most up-to-date analyzers.

The migration only resolves vulnerabilities that you haven’t confirmed or dismissed, and it doesn’t affect vulnerabilities that were automatically translated to Semgrep-based scanning.

Optional token expiration

Optional token expiration

Administrators can now decide if they want to enforce a mandatory expiration date for personal, project, and group access tokens. If administrators disable this setting, any new access token generated will not be required to have an expiration date. By default this setting is enabled, and an expiration less than that of the maximum allowed lifetime is required. This setting is available in GitLab 16.11 and later.

Secret Detection support for Anthropic API keys

Secret Detection support for Anthropic API keys

Both pipeline and client-side Secret Detection now support detection of Anthropic API keys.

Support suffix for jobs with name collisions in pipeline execution policy pipelines

Support suffix for jobs with name collisions in pipeline execution policy pipelines

An enhancement to the 17.2 release of pipeline execution policies, policy creators may now configure pipeline execution policies to handle collisions in job names gracefully. With the policy.yml for the pipeline execution policy, you may now configure the following options:

• suffix: on_conflict configures the policy to gracefully handle collisions by renaming policy jobs, which is the new default behavior
• suffix: never enforces all jobs names are unique and will fail pipelines if collisions occur, which has been the default behavior since 17.2

With this improvement, you can ensure security and compliance jobs executed within a pipeline execution policy always run, while also preventing unnecessary impacts to developers downstream.

In a follow-up enhancement, we will introduce the configuration option within the policy editor.