Enhanced merge request reviewer assignments
Enhanced merge request reviewer assignments
After you’ve carefully crafted your changes and prepared a merge request, the next step is to identify reviewers who can help move it forward. Identifying the right reviewers for your merge request involves understanding who the right approvers are, and who might be a subject matter expert (CODEOWNER) for the changes you’re proposing.
Now, when assigning reviewers, the sidebar creates a connection between the approval requirements for your merge request and reviewers. View each approval rule, then select from approvers who can satisfy that approval rule and move the merge request forward for you. If you use optional CODEOWNER sections those rules are also shown in the sidebar to help you identify appropriate subject matter experts for your changes.
Enhanced reviewer assignments is the next evolution of applying intelligence to assigned reviewers in GitLab. This iteration builds on what we’ve learned from suggested reviewers, and how to effectively identify the best reviewers for moving a merge request forward. In upcoming iterations of reviewer assignments, we’ll continue to enhance the intelligence used to recommend and rank possible reviewers.
Display release notes on deployment details page
Display release notes on deployment details page
Have you ever wondered what might be included in a deployment you’ve been asked to approve? In past versions, you could create a release with a detailed description about its content and instructions for testing, but the related environment-specific deployment did not show this data. We are happy to share that GitLab now displays the release notes under the related deployment details page.
Because GitLab releases are always created from a Git tag, the release notes are shown only on deployments related to the tag-triggered pipeline.
This feature was contributed to GitLab by Anton Kalmykov. Thank you!
Filter by Identifier on the Vulnerability Report
Filter by Identifier on the Vulnerability Report
On the project level Vulnerability Report you can now filter by vulnerability identifiers. This will allow you to find specific vulnerabilities that are in your project. For this iteration, filtering by identifier will be limited to the first 100 records. The identifier can be used in conjunction with other filters, i.e. severity, status, or tool.
Admin setting to enforce CI/CD job token allowlist
Admin setting to enforce CI/CD job token allowlist
Previously, we announced that the default CI/CD job token (CI_JOB_TOKEN) behavior will change in GitLab 18.0, requiring you to explicitly add indvidual projects or groups to your project’s job token allowlist if you want them to continue to be able to access your project.
Now, we are giving self-managed and Dedicated instance administrators the ability to enforce this more secure setting on all projects on an instance. After you enable this setting, all projects will need to make use of their allowlist if they want to use CI/CD job tokens for authentication. Note: We recommend enabling this setting as part of a strong security policy.
Track CI/CD job token authentications
Track CI/CD job token authentications
Previously it was difficult to track which other projects were using accessing your project by authenticating with CI/CD job tokens. To make it easier for you to audit and control access to your project, we’ve added an authentication log.
With this authentication log, you can view the list of other projects that have used a job token to authenticate with your project, both in the UI and as a downloadable CSV file. This data can be used to audit project access and aid in populating the job token allowlist to enable stronger control over which projects can access your project.
Vulnerability report grouping
Vulnerability report grouping
Users require the ability to view vulnerabilities in groups. This will help security analysts optimize their triage tasks by utilizing bulk actions. In addition users can see how many vulnerabilities match their group; i.e. how many OWASP Top 10 vulnerabilities are there?
Model registry now generally available
Model registry now generally available
GitLab’s model registry, now generally available, is your centralized hub for managing machine learning models as part of your existing GitLab workflow. You can track model versions, store artifacts and metadata, and maintain comprehensive documentation in the model card.
Built for seamless integration, the model registry works natively with MLflow clients and connects directly to your CI/CD pipelines, enabling automated model deployment and testing. Data scientists can manage models through an intuitive UI or existing MLflow workflows, while MLOps teams can leverage semantic versioning and CI/CD integration for streamlined production deployments all within the GitLab API.
Please feel free to drop us a note in our feedback issue and we’ll get back in touch! Get started today by going to Deploy > Model registry in your GitLab instance.
New tenant networking configurations for GitLab Dedicated
New tenant networking configurations for GitLab Dedicated
As a GitLab Dedicated tenant administrator, you can now use Switchboard to set up outbound private links and private hosted zones. You can also monitor your network connections by viewing periodic snapshots in Switchboard.
Outbound private links and private hosted zones establish secure network connectivity between resources in your AWS account and GitLab Dedicated.
Rotate personal access tokens in the UI
Rotate personal access tokens in the UI
You can now use the UI to rotate personal access tokens. Previously, you had to use the API to do this. A proposal to extend this functionality to project and group access tokens is in issue 504824.
Thank you shangsuru for your contribution!
New adherence checks for SAST and DAST security scanners
New adherence checks for SAST and DAST security scanners
GitLab offers a wide range of security scanners such as SAST, secret detection, dependency scanning, container scanning, and more so that you can check your applications for security vulnerabilities.
You need to have a way to show auditors and relevant compliance authorities that your applications have adhered to regulatory standards that require you to have security scanners set up for your repositories.
To help you demonstrate adherence to these standards, this release includes two new checks as part of the standard adherence report in the Compliance Centre. These new checks check whether SAST and DAST has been enabled for projects within a group. The checks confirm that the SAST and DAST security scanners correctly ran in a project and the pipeline results has the correct resulting artifacts.
