7.8 KiB
| stage | group | info | type | disqus_identifier |
|---|---|---|---|---|
| Create | Source Code | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments | reference, concepts | https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html |
Merge request approvals (FREE)
Redesign introduced in GitLab Premium 11.8 and feature flag removed in 12.0.
You can configure your merge requests so that they must be approved before they can be merged. You can do this by creating rules or by specifying a list of users who act as code owners for specific files.
You can configure merge request approvals for each project. In higher GitLab tiers, Administrators of self-managed GitLab instances can configure approvals for the entire instance.
How approvals work
With merge request approval rules, you can set the minimum number of required approvals before work can merge into your project. You can also extend these rules to define what types of users can approve work. Some examples of rules you can create include:
- Users with specific permissions can always approve work.
- Code owners can approve work for files they own.
- Users with specific permissions can approve work, even if they don't have merge rights to the repository.
- Users with specific permissions can be allowed or denied the ability to override approval rules on a specific merge request.
You can also configure additional settings for merge request approvals for more control of the level of oversight and security your project needs, including:
- Prevent users from overriding a merge request approval rule.
- Reset approvals when new code is pushed.
- Allow (or disallow) authors and committers to approve their own merge requests.
- Require password authentication when approving.
- Require security team approval.
You can configure your merge request approval rules and settings through the GitLab user interface or with the API.
Approve a merge request
When an eligible approver visits an open merge request, GitLab displays one of these buttons after the body of the merge request:
- Approve: The merge request doesn't yet have the required number of approvals.
- Approve additionally: The merge request has the required number of approvals.
- Revoke approval: The user viewing the merge request has already approved the merge request.
Eligible approvers can also use the /approve
quick action when adding a comment to
a merge request.
After a merge request receives the number and type of approvals you configure, it can merge unless it's blocked for another reason. Merge requests can be blocked by other problems, such as merge conflicts, pending discussions, or a failed CI/CD pipeline.
To prevent merge request authors from approving their own merge requests, enable Prevent author approval in your project's settings.
If you enable approval rule overrides, merge requests created before a change to default approval rules are not affected. The only exceptions are changes to the target branch of the rule.
Optional approvals
Introduced in GitLab 13.2.
GitLab allows all users with Developer or greater permissions to approve merge requests. Approvals in GitLab Free are optional, and don't prevent a merge request from merging without approval.
Required approvals (PREMIUM)
Moved to GitLab Premium in 13.9.
Required approvals enforce code reviews by the number and type of users you specify. Without the approvals, the work cannot merge. Required approvals enable multiple use cases:
- Enforce review of all code that gets merged into a repository.
- Specify reviewers for a given proposed code change, and a minimum number of reviewers, through Approval rules.
- Specify categories of reviewers, such as backend, frontend, quality assurance, or database, for all proposed code changes.
- Use the code owners of changed files, to determine who should review the work.
- Require approval from a security team before merging code that could introduce a vulnerability. (ULTIMATE)
Notify external services (ULTIMATE)
- Introduced in GitLab Ultimate 13.10.
- Deployed behind a feature flag, disabled by default.
- Disabled on GitLab.com.
- Not recommended for production use.
- To use in GitLab self-managed instances, ask a GitLab administrator to enable it. (ULTIMATE SELF)
WARNING: This feature might not be available to you. Check the version history note above for details.
You can create an external approval rule to integrate approvals with third-party tools. When users create, change, or close merge requests, GitLab sends a notification. The users of the third-party tools can then approve merge requests from outside of GitLab.
With this integration, you can integrate with third-party workflow tools, like ServiceNow, or the custom tool of your choice. You can modify your external approval rules by using the REST API.
The lack of an external approval doesn't block the merging of a merge request.
When approval rule overrides are allowed, changes to default approval rules will not be applied to existing merge requests, except for changes to the target branch of the rule.
To learn more about use cases, feature discovery, and development timelines, see the External API approval rules epic.
Related links
- Merge request approvals API
- Instance-level approval rules for self-managed installations