Automatic claims of enterprise users
Automatic claims of enterprise users
When a GitLab.com user’s primary email address matches an existing verified domain, the user is automatically claimed as an enterprise user. This gives the group Owner more user management controls and visibility into the user’s account. After a user becomes an enterprise user, they can only change their primary email to an email their organization owns as per its verified domains.
Minimal forking - only include the default branch
Minimal forking - only include the default branch
In previous versions of GitLab, when forking a repository, the fork always included all branches within the repository. Now you can create a fork with only the default branch, reducing complexity and storage space. Create minimal forks if you don’t need the changes that are currently being worked on in other branches.
The default method of forking will not change and continue to include all branches within the repository. The new option shows which branch is the default, so that you are aware of exactly which branch will be included in the new fork.
Allow users to enforce MR approvals as a compliance policy
Allow users to enforce MR approvals as a compliance policy
There is an increasing scrutiny on code changes that can potentially land in production applications and open businesses up to compliance risk and security vulnerability. With scan result policies, you can ensure unilateral changes cannot be made by enforcing two person approval on all merge requests.
Scan results policies have a new option to target Any merge request
which can be paired with defining role-based approvers to ensure each MR for the defined branches require approval by two (or more) users with a given role (Owner, Maintainer, or Developer).
Available in SaaS in 16.6. Available for Self-managed behind the feature flag scan_result_any_merge_request
and will be enabled by default in 16.7.
Switchboard portal for GitLab Dedicated is now generally available
Switchboard portal for GitLab Dedicated is now generally available
Switchboard, a new self-service portal, is now available for customers and team members to onboard, configure and maintain their GitLab Dedicated instances.
Using Switchboard, you can now make some configuration changes to your GitLab Dedicated instance. This functionality will expand in future releases.
CI/CD components Beta release
CI/CD components Beta release
In GitLab 16.1, we announced the release of an exciting experimental feature called CI/CD components. The component is a pipeline building block that can be listed in the upcoming CI/CD catalog.
Today we are excited to announce the Beta availability of CI/CD components. With this release, we have also improved the components folder structure from the initial experimental version. If you are already testing the experimental version of CI/CD components, it’s essential to migrate to the new folder structure. You can see some examples here. The old folder structure is deprecated and we plan to remove it within the next couple of releases.
If you try out CI/CD components, you are also welcome to try the new CI/CD catalog, currently available as an experimental feature. You can search the Global CI/CD catalog for components that others have created and published for public use. Additionally, if you create your own components, you can choose to publish them in the catalog too!
Improved UI for CI/CD variable management
Improved UI for CI/CD variable management
CI/CD variables are a fundamental part of GitLab CI/CD, and we felt that we could offer a better experience for working with variables from the settings UI. So in this release we’ve updated the UI to use a new drawer that improves the flow of adding and editing CI/CD variables.
For example, the masking validation used to only happen when you tried to save the CI/CD variable, and if it failed you’d have to restart from scratch. But now with the new drawer, you get real time validation so you can adjust on the fly without needed to redo anything!
Your feedback for this change is always valued and appreciated.
Runner Fleet Dashboard - Starter metrics (Beta)
Runner Fleet Dashboard - Starter metrics (Beta)
Operators of self-managed runner fleets need observability and the ability to quickly answer critical questions about their runner fleet infrastructure at a glance. Now, with the Runner Fleet Dashboard - Admin View (Beta), you have actionable insights to help you quickly answer critical fleet management and developer experience questions, starting with instance runners. These include answers to questions like which runners have errors, the performance of the runner queues for CI job execution, and which runners are most actively used. Ultimate customers can enable this feature independently, but are encouraged to participate in the early adopter’s program.
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