On August 15, 2024, GitLab 17.3 was released with the following features.
In addition, we want to thank all of our contributors, including this month's notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Anton Kalmykov is one of GitLab’s top contributors this year with 37 merged contributions since February and more in progress. Anton is a Senior Frontend Engineer at Yolo group (Bombay Games).
“Contributing to GitLab is one of the most challenging, ambitious, and exciting initiatives,” says Anton. “I appreciate the opportunity to be involved in creating and improving such a great product. Thanks to this chance, I have learned a lot of new things, and I still have a lot to do. I am incredibly grateful to the GitLab team, especially those who have checked my MRs, guided me, and helped me do things right.”
Anton was nominated by Christina Lohr, Senior Product Manager at GitLab, for helping out the Tenant Scale group with several frontend issues.
“We have a lot of smaller UX improvements to work through for our basic workflows, and it is great to get help from the community to complete these initiatives faster,” says Christina. “All these improvements are helping to create a more cohesive user experience between groups and projects. Thank you Anton.”
Many thanks to Anton and the rest of GitLab’s open source contributors for co-creating GitLab!
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.
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.
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.
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.
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.
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.
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).
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!
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.
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.
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.
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.
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.
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:
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.
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!
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.
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.
For a list of all changes, see the GitLab Runner changelog.