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.
Support for private container registries in workspaces
Support for private container registries in workspaces
GitLab workspaces now offer support for private container registries. With this setup, you can pull container images from any private registry of your choice. As long as your Kubernetes cluster has a valid image pull secret, you can reference the secret in your GitLab agent configuration.
This feature simplifies workflows, especially for teams that use custom or third-party container registries, and improves the flexibility and security of containerized development environments.
Extension marketplace now available in workspaces
Extension marketplace now available in workspaces
The extension marketplace is now available in workspaces. With the extension marketplace, you can discover, install, and manage third-party extensions to enhance your development experience. Choose from thousands of extensions to boost your productivity or customize your workflow.
The extension marketplace is disabled by default. To get started, go to your user preferences and enable the extension marketplace. For enterprise users, only users with the Owner role for a top-level group can enable the extension marketplace.
Improved workspace lifecycle with delayed termination
Improved workspace lifecycle with delayed termination
With this release, a workspace now stops rather than terminates after the configured timeout has elapsed. This feature means you can always restart your workspaces and pick up where you left off.
By default, a workspace automatically:
- Stops 36 hours after the workspace was last started or restarted
- Terminates 722 hours after the workspace was last stopped
You can configure these settings in your GitLab agent configuration.
With this feature, a workspace remains available for approximately one month after it was stopped. This way, you get to keep your progress while optimizing workspace resources.
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!
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.
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.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback