GitLab.org/GitLab: Release v17.3.0-ee

We have shipped performance improvements with the recent upgrade to macOS 14.5 and Xcode 15.4. With this change, Xcode build jobs are significantly faster compared to previous job executions.

We are excited to announce a significant improvement to our AI Impact analytics with the introduction of sparklines. These small, simple graphs embedded in data tables enhance the readability and accessibility of AI Impact data. By transforming numerical values into visual representations, the new sparklines make it easier to identify trends over time, so you can spot upward or downward movements. This new visual approach also streamlines the process of comparing trends across multiple metrics, reducing the time and effort required when relying solely on numbers.

These two new metrics highlight the effectiveness and utilization of GitLab Duo, and are now included in the AI Impact analytics in the Value Streams Dashboard, which helps organizations understand the impact of GitLab Duo on delivering business value.

The Code Suggestions acceptance rate metric indicates how frequently developers accept code suggestions made by GitLab Duo. This metric reflects both the effectiveness of these suggestions and the level of trust contributors have in AI capabilities. Specifically, the metric represents the percentage of code suggestions provided by GitLab Duo that have been accepted by code contributors in the last 30 days.

The GitLab Duo seats assigned and used metric shows the percentage of consumed licensed seats, helping organizations plan effectively for license utilization, resource allocation, and understanding of usage patterns. This metric tracks the ratio of assigned seats that have used at least one AI feature in the last 30 days.

With the addition of these new metrics, we have also introduced new overview tiles — a new visualization which provides a clear summary of the metrics, helping you quickly assess the current state of your AI features.

Root cause analysis is now generally available. With root cause analysis, you can troubleshoot failed jobs in CI/CD pipelines faster. This AI-powered feature analyzes the failed job log, quickly determines the root cause of the job failure, and suggests a fix for you.

Composition Analysis has delivered Rust support for Dependency and License Scanning. Rust scanning supports the Cargo.lock file type.

To enable Rust scanning for your Project use the cargo template from the Dependency Scanning CI/CD Component.

GitLab 15.3 added support for ingesting CycloneDX SBOMs. While the SBOM reports are validated against the CycloneDX schema, any warnings and errors produced as part of validation were not displayed to the user.

In GitLab 17.3 these validation messages appear in the GitLab UI on the project-level Vulnerability Report and Dependency List pages.

Users will be able to view SBOM ingestion errors in the following areas of the GitLab UI: the project level vulnerability report and dependency list pages, the licenses and security tabs of the pipeline page.

You can customize the rules used in SAST, IaC Scanning, and Secret Detection by creating a local configuration file committed in the repository or by setting a CI/CD variable to apply a shared configuration across multiple projects.

Previously, scanners preferred the local configuration file, even if you also set a shared ruleset reference. This precedence order made it difficult to ensure that scans would use a known, trusted ruleset.

Now, we've added a new CI/CD variable, SECURE_ENABLE_LOCAL_CONFIGURATION, to control whether local configuration files are allowed. It defaults to true, which keeps the existing behavior: local configuration files are allowed and are preferred over shared configurations. If you set the value to false when you enforce scan execution, you can be sure that scans use your shared ruleset, or the default ruleset, even if project developers add a local configuration file.

External status checks can now be configured with HMAC (Hash-based Message Authentication Code) authentication. This will provide a more secure way to verify the authenticity of requests from GitLab to external services.

When enabled for your status check, a shared secret is used to generate a unique signature for each request. The signature is sent in the X-Gitlab-Signature header, using SHA256 as the hash algorithm.

• Improved Security: HMAC authentication prevents tampering with requests and ensures they come from a legitimate source.
• Compliance: This feature is particularly valuable for regulated industries, such as banking, where security is paramount.
• Backwards Compatibility: The feature will be optional and backwards compatible. Users can choose to enable HMAC authentication for new or existing checks, but existing external status checks will continue to function without changes.

In a future iteration, GitLab plans to add an option to also verify and block HTTP requests.

Organizations that use LDAP group links to manage user permissions for groups can already use default roles for membership.

In this release, we're extending that support to custom roles. This configuration makes it easier to map access to a large group of users.

You can create custom roles with the following new permission:

• Read Runners

With custom roles, you can reduce the number of users with the Owner role by creating users with equivalent permissions. This helps you define roles that are tailored to the needs of your group, and prevents users from being given more privileges than they need.

Vulnerability resolution uses AI to give specific code suggestions for users to fix vulnerabilities. With the click of a button you can open a merge request to get started resolving any SAST vulnerability from the list of supported CWE identifiers.

When you enable advanced search in GitLab, you can now select Index the instance to perform initial indexing or re-create an index from scratch. This setting achieves functional parity with the gitlab:elastic:index rake task by indexing all supported types of data into the integrated Elasticsearch or OpenSearch cluster.

Index the instance replaces the setting to index all projects, which was limited to the initial indexing only.

Because the agent for Kubernetes allows bi-directional data flow between a Kubernetes cluster and GitLab, it's important to know when a component that can access your systems is added or removed. In past releases, compliance teams had to use custom tooling or search for this data in GitLab directly. GitLab now provides the following audit events:

• cluster_agent_created records who registered a new agent for Kubernetes.
• cluster_agent_create_failed records who tried to register a new agent for Kubernetes but failed.
• cluster_agent_deleted records who removed an agent for Kubernetes registration.
• cluster_agent_delete_failed records who tried to remove an agent for Kubernetes registration but failed.

These audit events extend the cluster_agent_token_created and cluster_agent_token_revoked audit events to further improve the ability to audit your GitLab instance.

Since GitLab 9.3 you can view project webhook request history in the UI, and since GitLab 15.3 you can also view group webhook request history in the UI.

In this release, that data is now exposed in the REST API, which can help you automate processes to discover and respond to webhook errors. You can get a list of events for a specific project hook and group hook in the past 7 days.

Thanks to Phawin for this community contribution!

You can now troubleshoot the setup for GitLab Duo on your self-managed instance. In the Admin area, on the GitLab Duo page, select Run health check. This health check performs a series of validations and suggests appropriate corrective actions to ensure GitLab Duo is operational.

The health check for GitLab Duo is available on Self-managed and GitLab Dedicated as a beta feature.

To improve the tracking of merge request (MR) review time in GitLab, we added a new stage event to Value Stream Analytics: MR first reviewer assigned. With this new event teams can identify where delays occur in the review process, find opportunities to improve collaboration, and encourage a culture of responsiveness and accountability among team members. Reducing the review time directly impacts the overall cycle time of development, leading to faster software delivery. For example, you can now add a new custom Review Time to Merge (RTTM) stage that starts with MR first reviewer assigned and ends with MR merged.

Get more control over your coding experience in VS Code by enabling or disabling code suggestions for specific programming languages. This granular control allows you to customize your workflow, reducing irrelevant or intrusive suggestions while maintaining the benefits of code suggestions for your preferred languages.

You can now visualize the merge train to gain better insight into the status and order of merge requests in the pipeline. With merge train visualization, you can identify conflicts earlier, take actions on merge requests directly in the merge train, and minimize the risk of breaking the default branch.

You can create a compliance framework to identify that your project has certain compliance requirements or needs additional oversight. The compliance framework can optionally enforce compliance pipeline configuration to the projects on which it is applied.

Previously, users could only apply one compliance framework to a project, which limited how many compliance requirements could be set on a project. We have now provided the ability for a user to apply multiple compliance frameworks per project. This will allow users to apply multiple different compliance frameworks onto a single project at a given time. With this release, you can apply multiple compliance frameworks to a project. The project is then set with the compliance requirements of each framework.

GitLab 17.3 includes packages for supporting Raspberry Pi OS 12.

Debian 10 has reached EOL on June 30th, 2024. GitLab will remove support for Debian 10 in GitLab 17.6.

We have updated the sorting and filtering functionality of the project and group overview in Your Work. Previously, in the Your Work page for projects, you could filter by name and language, and use a pre-defined set of sorting options. We have standardized the sorting options to include Name, Created date, Updated date, and Stars. We also added a navigation element to sort in ascending or descending order, and moved the language filter to the filter menu. Now you can find archived projects in the new Inactive tab. Additionally, we added a Role filter that allows you to search for projects you are the Owner of.

In the Your Work page for groups, we have standardized the sorting options to include Name, Created date, and Updated date, and added a navigation element to sort in ascending or descending order.

We welcome feedback about these changes in #438322.

This release adds full support for Kubernetes version 1.30, released in April 2024. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.

You can read more about our Kubernetes support policy and other supported Kubernetes versions.

Until now, you could only control whether a project inherited integration settings, or used its own settings, using the UI.

In this milestone, we are introducing a new use_inherited_settings parameter to the REST API of all integrations. This parameter allows you to use the API to set whether or not a project inherits integration settings. If not set, the default behavior is false (use the project's own settings).

In 17.2, we added the ability to search for project settings by using the command palette. This change made it easier to quickly find the settings you need.

With 17.3, you can now search for group settings from the command palette as well. Try it out by visiting a group, selecting Search or go to, entering command mode with >, and typing the name of a settings section, like Merge request approvals. Select a result to jump right to the setting itself.

Have you ever needed to restart or delete a failing pod in Kubernetes? Until now, you had to leave GitLab, use another tool to connect to the cluster, stop the pod, and wait for a new pod to start. GitLab now has built-in support for deleting pods, so you can smoothly troubleshoot your Kubernetes clusters.

You can stop a pod from a dashboard for Kubernetes, which lists all the pods across your cluster or namespace.

Do you want to connect to a Kubernetes cluster from your local terminal or using one of the desktop Kubernetes GUI tools? GitLab allows you to connect to a terminal using the user access feature of the agent for Kubernetes. Previously, finding commands required navigating out of GitLab to browse the documentation. Now, GitLab provides the connect command from the UI. GitLab can even help you configure user access!

To retrieve the connection command, either go to a Kubernetes dashboard, or to the agent list.

Tasks are frequently used to break down issues into engineering implementation steps. Before this release, there was no way to connect a merge request to a task it implements. You can now use the same closing pattern that you would when referencing issues from a merge request description to connect a merge request to a task. From the task view, connected merge requests are visible from the sidebar. If your project has the auto-close setting enabled, the task will automatically close when the connected merge request is merged into your default branch.

You can now effortlessly update parent assignments for OKRs and tasks, directly from the child record, eliminating the need to navigate back and forth. This is a great step towards our goal of improving efficiency with your workflows.

You can now easily report abuse for work items directly from the Actions menu, just like you can with legacy issues. This new feature helps keep your workspace clean and safe by allowing you to quickly flag inappropriate content, ensuring a better collaborative environment for your team.

You can now resolve threads in tasks, objectives, and key results, making it easier to manage and track important conversations. Resolved threads are collapsed by default, helping you focus on active discussions and streamline your collaboration workflows.

For tighter security in sensitive environments, you can now configure custom HTTP agent options, including client certificates and certificate authorities, directly in your JetBrains IDE settings.

Currently, the process for removing content from a repository is complicated, and you might have to force push the project to GitLab. This is prone to errors and can cause you to temporarily turn off protections to enable the push. It can be even harder to delete files that use too much space within the repository.

You can now use the new repository maintenance option in project settings to remove blobs based on a list of object IDs. With this new method, you can selectively remove content without the need to force push a project back to GitLab.

In the event that secrets or other content has been pushed that needs to be redacted from a project, we're also introducing a new option to redact text. Provide a string that GitLab will replace with ***REMOVED*** in files across the project. After the text has been redacted, run housekeeping to remove old versions of the string.

This new UI streamlines the way you can manage your repositories when content needs to be removed.

You can now quickly find a specific job by searching for a job name.

Previously, you could only filter the list of jobs by status, requiring manual scrolling to find a specific job. With this release, you can now enter a job name to filter the results. The results will only include jobs in pipelines that ran after the release of GitLab 17.3.

We're releasing GitLab Runner 17.3 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:

• Jobs appear to hang when canceled in the Kubernetes runner
• Log level not updated when not specified
• Job log adds extra newlines when using the runner Kubernetes executor

For a list of all changes, see the GitLab Runner changelog.

The details page for a CI/CD component in the catalog provides useful information about the component. In this release we've added two more columns to the table that shows information about available inputs. The new Description and Type columns make it much easier to understand what an input is used for, and what type of value is expected.

Users can now filter the Members page by role. Use the filter to find members with a specific role.

Previously, if you wanted to view permissions for the custom roles of a user, you had to have the Owner role in the group. This requirement made it difficult to troubleshoot and understand what actions a user can perform when assigned a custom role. Now, any user can view the permissions of a user assigned a custom role in the Members page.

Administrators can now disable or re-enable instance personal access tokens through the Admin UI. Previously, administrators had to use the application settings API or the GitLab Rails console to do this.

You can now add your Bluesky did:plc identifier to your GitLab profile.

Thank you Dominique for your contribution!

GitLab's sign out process has been improved so that cookies from sibling subdomains are not deleted on sign out. Previously, these cookies were deleted, causing users to be signed out of other subdomain services on the same top-level domain as GitLab. For example, if a user has Kibana set up on kibana.example.com and GitLab set up on gitlab.example.com, signing out from GitLab will no longer sign the user out from Kibana.

Thank you Guilherme C. Souza for your contribution!