New features are regularly released to GitLab SaaS (GitLab.com), with a packaged release available for GitLab Self-Managed every month. Read on to learn more about the new features available on GitLab.com. Note that it may take a few days for a feature to become fully available on GitLab.com, due to deployment schedule and potential
feature flags.
Additional information on
past
releases is available; be sure to check out the
release for other features we've launched recently. We also have information about
upcoming releases
if you're interested in seeing what we are doing next.
Preview
Key improvements released in GitLab Preview
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!
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.
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.
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.
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.
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).
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.
Now you can 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
To improve the tracking of merge request (MR) review time in GitLab, we added to the Value Stream Analytics a new stage event: 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.
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.
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.
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.
Now you can 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 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.
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.
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, 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.
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.
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.
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.
