Instance administrators can control which integrations can be enabled
Instance administrators can control which integrations can be enabled
Instance administrators can now configure an allowlist to control which integrations can be enabled on a GitLab instance. If an empty allowlist is configured, no integrations are allowed on the instance. After an allowlist is configured, new GitLab integrations are not on the allowlist by default.
Previously enabled integrations that are later blocked by the allowlist settings are disabled. If these integrations are allowed again, they are re-enabled with their existing configuration.
New user contribution and membership mapping available in direct transfer
New user contribution and membership mapping available in direct transfer
The new method of user contribution and membership mapping is now available when you migrate between GitLab instances by direct transfer. This feature offers flexibility and control for both users managing the import process and users receiving contribution reassignments. With the new method, you can:
- Reassign memberships and contributions to existing users on the destination instance after the import has completed. Any memberships and contributions you import are first mapped to placeholder users. All contributions appear associated with placeholders until you reassign them on the destination instance.
- Map memberships and contributions for users with different email addresses on source and destination instances.
When you reassign a contribution to a user on the destination instance, the user can accept or reject the reassignment.
For more information, see streamline migrations with user contribution and membership mapping. To leave feedback, add a comment to issue 502565.
Auto-resolve vulnerabilities when not found in subsequent scans
Auto-resolve vulnerabilities when not found in subsequent scans
GitLab’s security scanning tools help identify known vulnerabilities and potential weaknesses in your application code. Scanning feature branches surfaces new weaknesses or vulnerabilities so they can be remediated before merging. In the case of vulnerabilities already in your project’s default branch, fixing these in a feature branch will mark the vulnerability as no longer detected when the next default branch scan runs. While it is informative to know which vulnerabilities are no longer detected, each must still be manually marked as Resolved to close them. This can be time consuming if there are many of these to resolve, even when using the new Activity filter and bulk-changing status.
We are introducing a new policy type Vulnerability Management policy for users who want vulnerabilities automatically set to Resolved when no longer detected by automated scanning. Simply configure a new policy with the new Auto-resolve option and apply it to the appropriate project(s). You can even configure the policy to only Auto-resolve vulnerabilities of a certain severity or from specific security scanners. Once in place, the next time the project’s default branch is scanned, any existing vulnerabilities that are no longer found will be marked as Resolved. The action updates the vulnerability record with an activity note, timestamp when the action occurred, and the pipeline the vulnerability was determined to be removed in.
Rotate personal, project, and group access tokens in the UI
Rotate personal, project, and group access tokens in the UI
You can now use the UI to rotate personal, project, and group access tokens. Previously, you had to use the API to do this.
Thank you shangsuru for your contribution!
Track CI/CD component usage across projects
Track CI/CD component usage across projects
Central DevOps teams often need to track where their CI/CD components are used across pipelines to better manage and optimize them. Without visibility, it’s challenging to identify outdated component use, understand adoption rates, or support component life cycles.
To address this, we’ve added a new GraphQL query that enables DevOps teams to view a list of projects where a component is used across their organization’s pipelines. This capability empowers DevOps teams to enhance productivity and make better decisions by providing crucial insights.
Small hosted runner on Linux Arm available to all Tiers
Small hosted runner on Linux Arm available to all Tiers
We are excited to introduce the small hosted runner on Linux Arm for GitLab.com, available for all tiers. This 2 vCPUs Arm runner is fully integrated with GitLab CI/CD and allows you to build and test applications natively on the Arm architecture.
We are determined to provide the industry’s fastest CI/CD build speed and look forward to seeing teams achieve even shorter feedback cycles and ultimately deliver software faster.
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