Skip to content

G
gitlab-ce
Commit ab06cec8 authored by Amy Qualls's avatar Amy Qualls
Browse files
Options

Merge branch '324948-aqualls-approvals' into 'master' 

Begin splitting merge request approvals page

See merge request gitlab-org/gitlab!60447
parents 8f709166 53d69542
Show whitespace changes
Inline Side-by-side
Showing with 469 additions and 448 deletions
doc/api/merge_request_approvals.md
View file @ ab06cec8
......@@ -8,7 +8,7 @@ type: reference, api
# Merge request approvals API **(PREMIUM)**
Configuration for
[approvals on all merge requests](../user/project/merge_requests/merge_request_approvals.md)
[approvals on all merge requests](../user/project/merge_requests/approvals/index.md)
in the project. Must be authenticated for all endpoints.
## Project-level MR approvals
......@@ -1068,7 +1068,7 @@ POST /projects/:id/merge_requests/:merge_request_iid/approve
| `id` | integer | yes | The ID of a project |
| `merge_request_iid` | integer | yes | The IID of MR |
| `sha` | string | no | The HEAD of the MR |
| `approval_password` **(PREMIUM)** | string | no | Current user's password. Required if [**Require user password to approve**](../user/project/merge_requests/merge_request_approvals.md#require-authentication-when-approving-a-merge-request) is enabled in the project settings. |
| `approval_password` **(PREMIUM)** | string | no | Current user's password. Required if [**Require user password to approve**](../user/project/merge_requests/approvals/settings.md#require-authentication-when-approving-a-merge-request) is enabled in the project settings. |
The `sha` parameter works in the same way as
when [accepting a merge request](merge_requests.md#accept-mr): if it is passed, then it must
......
doc/development/approval_rules.md
View file @ ab06cec8
......@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Approval Rules development guide **(FREE)**
This document explains the backend design and flow of all related functionality
about [merge request approval rules](../user/project/merge_requests/merge_request_approvals.md).
about [merge request approval rules](../user/project/merge_requests/approvals/index.md).
This should help contributors to understand the code design easier and to also
help see if there are parts to improve as the feature and its implementation
......@@ -87,7 +87,7 @@ The `ApprovalState` model get these records when approval rules are not
overwritten.
The `protected_branches` attribute is set and used when a rule is scoped to
protected branches. See [Scoped to Protected Branch doc](../user/project/merge_requests/merge_request_approvals.md#scoped-to-protected-branch)
protected branches. See [Scoped to Protected Branch doc](../user/project/merge_requests/approvals/rules.md#scoped-to-protected-branch)
for more information about the feature.
### `ApprovalMergeRequestRule`
......
doc/development/code_review.md
View file @ ab06cec8
......@@ -39,7 +39,7 @@ or more [maintainers](https://about.gitlab.com/handbook/engineering/workflow/cod
For approvals, we use the approval functionality found in the merge request
widget. For reviewers, we use the [reviewer functionality](../user/project/merge_requests/getting_started.md#reviewer) in the sidebar.
Reviewers can add their approval by [approving additionally](../user/project/merge_requests/merge_request_approvals.md#adding-or-removing-an-approval).
Reviewers can add their approval by [approving additionally](../user/project/merge_requests/approvals/index.md#adding-or-removing-an-approval).
Getting your merge request **merged** also requires a maintainer. If it requires
more than one approval, the last maintainer to review and approve merges it.
......
doc/development/contributing/index.md
View file @ ab06cec8
......@@ -152,7 +152,7 @@ Keep the following in mind when submitting merge requests:
reviewer will have reservations about the code's overall quality. When there is a reservation,
the reviewer will inform the author and provide some guidance.
- Though GitLab generally allows anyone to indicate
[approval](../../user/project/merge_requests/merge_request_approvals.md) of merge requests, the
[approval](../../user/project/merge_requests/approvals/index.md) of merge requests, the
maintainer may require [approvals from certain reviewers](../code_review.md#approval-guidelines)
before merging a merge request.
- After review, the author may be asked to update the merge request. Once the merge request has been
......
doc/development/integrations/secure_partner_integration.md
View file @ ab06cec8
......@@ -47,7 +47,7 @@ best place to integrate your own product and its results into GitLab.
displays the results of the pipeline's security checks and the developer can
review them. The developer can review both a summary and a detailed version
of the results.
- If certain policies (such as [merge request approvals](../../user/project/merge_requests/merge_request_approvals.md))
- If certain policies (such as [merge request approvals](../../user/project/merge_requests/approvals/index.md))
are in place for a project, developers must resolve specific findings or get
an approval from a specific list of people.
- The [security dashboard](../../user/application_security/security_dashboard/index.md)
......
doc/subscriptions/bronze_starter.md
View file @ ab06cec8
......@@ -64,12 +64,12 @@ the tiers are no longer mentioned in GitLab documentation:
- [`elasticsearch.log`](../administration/logs.md#elasticsearchlog)
- Merge requests:
- [Full code quality reports in the code quality tab](../user/project/merge_requests/code_quality.md#code-quality-reports)
- [Merge request approvals](../user/project/merge_requests/merge_request_approvals.md)
- [Merge request approvals](../user/project/merge_requests/approvals/index.md)
- [Multiple assignees](../user/project/merge_requests/getting_started.md#multiple-assignees)
- [Approval Rule information for Reviewers](../user/project/merge_requests/getting_started.md#approval-rule-information-for-reviewers) **(PREMIUM)**
- [Required Approvals](../user/project/merge_requests/merge_request_approvals.md#required-approvals)
- [Code Owners as eligible approvers](../user/project/merge_requests/merge_request_approvals.md#code-owners-as-eligible-approvers)
- [Approval rules](../user/project/merge_requests/merge_request_approvals.md#approval-rules) features
- [Required Approvals](../user/project/merge_requests/approvals/index.md#required-approvals)
- [Code Owners as eligible approvers](../user/project/merge_requests/approvals/rules.md#code-owners-as-eligible-approvers)
- [Approval rules](../user/project/merge_requests/approvals/rules.md) features
- [Restricting push and merge access to certain users](../user/project/protected_branches.md#restricting-push-and-merge-access-to-certain-users)
- [Visual Reviews](../ci/review_apps/index.md#visual-reviews)
- Metrics and analytics:
......@@ -130,7 +130,7 @@ Bronze-level subscribers:
- Project milestones API: [Get all burndown chart events for a single milestone](../api/milestones.md#get-all-burndown-chart-events-for-a-single-milestone)
- [Project iterations API](../api/iterations.md)
- Fields in the [Search API](../api/search.md) available only to [Advanced Search (Elasticsearch)](../integration/elasticsearch.md) users
- Fields in the [Merge requests API](../api/merge_requests.md) for [merge request approvals](../user/project/merge_requests/merge_request_approvals.md)
- Fields in the [Merge requests API](../api/merge_requests.md) for [merge request approvals](../user/project/merge_requests/approvals/index.md)
- Fields in the [Protected branches API](../api/protected_branches.md) that specify users or groups allowed to merge
- [Merge request approvals API](../api/merge_request_approvals.md)
- [Visual review discussions API](../api/visual_review_discussions.md)
......
doc/user/admin_area/merge_requests_approvals.md
View file @ ab06cec8
......@@ -32,4 +32,4 @@ any commits to the source branch.
- **Prevent users from modifying merge request approvers list**. Prevents users from
modifying the approvers list in project settings or in individual merge requests.
Also read the [project level merge request approval rules](../project/merge_requests/merge_request_approvals.md), which are affected by instance level rules.
Also read the [project level merge request approval rules](../project/merge_requests/approvals/index.md), which are affected by instance level rules.
doc/user/application_security/index.md
View file @ ab06cec8
......@@ -297,7 +297,7 @@ rating.
### Enabling Security Approvals within a project
To enable the `Vulnerability-Check` or `License-Check` Security Approvals, a [project approval rule](../project/merge_requests/merge_request_approvals.md#adding--editing-a-default-approval-rule)
To enable the `Vulnerability-Check` or `License-Check` Security Approvals, a [project approval rule](../project/merge_requests/approvals/rules.md#adding--editing-a-default-approval-rule)
must be created. A [security scanner job](#security-scanning-tools) must be enabled for
`Vulnerability-Check`, and a [license scanning](../compliance/license_compliance/index.md#configuration)
job must be enabled for `License-Check`. When the proper jobs aren't configured, the following
......
doc/user/compliance/compliance_dashboard/index.md
View file @ ab06cec8
......@@ -46,9 +46,9 @@ We support a separation of duties policy between users who create and approve Me
The approval status column can help you identify violations of this policy.
Our criteria for the separation of duties is as follows:
- [A Merge Request author is **not** allowed to approve their Merge Request](../../project/merge_requests/merge_request_approvals.md#allowing-merge-request-authors-to-approve-their-own-merge-requests)
- [A Merge Request committer is **not** allowed to approve a Merge Request they have added commits to](../../project/merge_requests/merge_request_approvals.md#prevent-approval-of-merge-requests-by-their-committers)
- [The minimum number of approvals required to merge a Merge Request is **at least** two](../../project/merge_requests/merge_request_approvals.md#approval-rules)
- [A Merge Request author is **not** allowed to approve their Merge Request](../../project/merge_requests/approvals/settings.md#allowing-merge-request-authors-to-approve-their-own-merge-requests)
- [A Merge Request committer is **not** allowed to approve a Merge Request they have added commits to](../../project/merge_requests/approvals/settings.md#prevent-approval-of-merge-requests-by-their-committers)
- [The minimum number of approvals required to merge a Merge Request is **at least** two](../../project/merge_requests/approvals/rules.md)
The "Approval status" column shows you, at a glance, whether a Merge Request is complying with the above.
This column has four states:
......
doc/user/index.md
View file @ ab06cec8
......@@ -56,7 +56,7 @@ GitLab is a Git-based platform that integrates a great number of essential tools
With GitLab Enterprise Edition, you can also:
- Improve collaboration with:
- [Merge Request Approvals](project/merge_requests/merge_request_approvals.md).
- [Merge Request Approvals](project/merge_requests/approvals/index.md).
- [Multiple Assignees for Issues](project/issues/multiple_assignees_for_issues.md).
- [Multiple Issue Boards](project/issue_board.md#multiple-issue-boards).
- Create formal relationships between issues with [linked issues](project/issues/related_issues.md).
......
doc/user/permissions.md
View file @ ab06cec8
......@@ -202,7 +202,7 @@ The following table depicts the various user permission levels in a project.
1. Actions are limited only to records owned (referenced) by user.
1. When [Share Group Lock](group/index.md#prevent-a-project-from-being-shared-with-groups) is enabled the project can't be shared with other groups. It does not affect group with group sharing.
1. For information on eligible approvers for merge requests, see
[Eligible approvers](project/merge_requests/merge_request_approvals.md#eligible-approvers).
[Eligible approvers](project/merge_requests/approvals/rules.md#eligible-approvers).
1. Applies only to comments on [Design Management](project/issues/design_management.md) designs.
1. Users can only view events based on their individual actions.
1. Project access tokens are supported for self-managed instances on Free and above. They are also
......
doc/user/project/clusters/protect/container_network_security/quick_start_guide.md
View file @ ab06cec8
......@@ -52,7 +52,7 @@ Each method has benefits and drawbacks:
| | YAML method | UI method (Ultimate only) |
|--|:------------|:-------------------------------|
| **Benefits** | A change control process is possible by requiring [MR Approvals](../../../merge_requests/merge_request_approvals.md). All changes are fully tracked and audited in the same way that Git tracks the history of any file in its repository. | The UI provides a simple rules editor for users who are less familiar with the YAML syntax of NetworkPolicies. This view is a live representation of the policies currently deployed in the Kubernetes cluster. The UI also allows for multiple network policies to be created per environment. |
| **Benefits** | A change control process is possible by requiring [MR Approvals](../../../merge_requests/approvals/index.md). All changes are fully tracked and audited in the same way that Git tracks the history of any file in its repository. | The UI provides a simple rules editor for users who are less familiar with the YAML syntax of NetworkPolicies. This view is a live representation of the policies currently deployed in the Kubernetes cluster. The UI also allows for multiple network policies to be created per environment. |
| **Drawbacks** | Only one network policy can be deployed per environment (although that policy can be as detailed as needed). Also, if changes were made in Kubernetes directly rather than through the `auto-deploy-values.yaml` file, the YAML file's contents don't represent the actual state of policies deployed in Kubernetes. | Policy changes aren't audited and a change control process isn't available. |
Users are encouraged to choose one of the two methods to manage their policies. If users attempt to
......
doc/user/project/code_owners.md
View file @ ab06cec8
......@@ -76,7 +76,7 @@ The user that would show for `README.md` would be `@user2`.
After you've added Code Owners to a project, you can configure it to
be used for merge request approvals:
- As [merge request eligible approvers](merge_requests/merge_request_approvals.md#code-owners-as-eligible-approvers).
- As [merge request eligible approvers](merge_requests/approvals/rules.md#code-owners-as-eligible-approvers).
- As required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)**
Developer or higher [permissions](../permissions.md) are required to
......@@ -87,9 +87,9 @@ After it's set, Code Owners are displayed in merge request widgets:
![MR widget - Code Owners](img/code_owners_mr_widget_v12_4.png)
While you can use the `CODEOWNERS` file in addition to Merge Request
[Approval Rules](merge_requests/merge_request_approvals.md#approval-rules),
[Approval Rules](merge_requests/approvals/rules.md),
you can also use it as the sole driver of merge request approvals
without using [Approval Rules](merge_requests/merge_request_approvals.md#approval-rules):
without using [Approval Rules](merge_requests/approvals/rules.md):
1. Create the file in one of the three locations specified above.
1. Set the code owners as required approvers for
......
doc/user/project/index.md
View file @ ab06cec8
......@@ -45,7 +45,7 @@ Projects include the following [features](https://about.gitlab.com/features/):
- [Multiple Issue Boards](issue_board.md#multiple-issue-boards): Create team-specific workflows (Issue Boards) for a project.
- [Merge Requests](merge_requests/index.md): Apply a branching
strategy and get reviewed by your team.
- [Merge Request Approvals](merge_requests/merge_request_approvals.md): Ask for approval before
- [Merge Request Approvals](merge_requests/approvals/index.md): Ask for approval before
implementing a change.
- [Fix merge conflicts from the UI](merge_requests/resolve_conflicts.md): View Git diffs from the GitLab UI.
- [Review Apps](../../ci/review_apps/index.md): By branch, preview the results
......
doc/user/project/merge_requests/approvals/index.md 0 → 100644
View file @ ab06cec8
---
stage: Create
group: Source Code
info: "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"
type: reference, concepts
disqus_identifier: 'https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html'
---
# Merge Request Approvals **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/580) in GitLab Enterprise Edition 7.2. Available in GitLab Free and higher tiers.
> - Redesign [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8 and [feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/10685) in 12.0.
Code review is an essential practice of every successful project. Approving a
merge request is an important part of the review
process, as it clearly communicates the ability to merge the change.
A [merge request approvals API](../../../../api/merge_request_approvals.md) is also available.
## Optional Approvals
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27426) in GitLab 13.2.
Any user with Developer or greater [permissions](../../../permissions.md) can approve a merge request in GitLab Free and higher tiers.
This provides a consistent mechanism for reviewers to approve merge requests, and ensures
maintainers know a change is ready to merge. Approvals in Free are optional, and do
not prevent a merge request from being merged when there is no approval.
## External approvals **(ULTIMATE)**
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3869) in GitLab Ultimate 13.10.
> - It's [deployed behind a feature flag](../../../feature_flags.md), disabled by default.
> - It's disabled on GitLab.com.
> - It's not recommended for production use.
> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](../../../../api/merge_request_approvals.md#enable-or-disable-external-project-level-mr-approvals). **(ULTIMATE SELF)**
WARNING:
This feature might not be available to you. Check the **version history** note above for details.
When you create an external approval rule, the following merge request actions sends information
about a merge request to a third party service:
- Create
- Change
- Close
This action enables use-cases such as:
- Integration with 3rd party workflow tools, such as [ServiceNow](https://www.servicenow.co.uk/).
- Integration with custom tools designed to approve merge requests from outside of GitLab.
You can find more information about use-cases, development timelines and the feature discovery in
the [External API approval rules epic](https://gitlab.com/groups/gitlab-org/-/epics/3869).
The intention for this feature is to allow those 3rd party tools to approve a merge request similarly to how users current do.
NOTE:
The lack of an external approval does not block the merging of a merge request.
You can modify external approval rules through the [REST API](../../../../api/merge_request_approvals.md#external-project-level-mr-approvals).
## Required Approvals **(PREMIUM)**
> - [Introduced](https://about.gitlab.com/releases/2015/06/22/gitlab-7-12-released/#merge-request-approvers-ee-only) in GitLab Enterprise Edition 7.12.
> - Moved to GitLab Premium in 13.9.
Required approvals enable enforced code review by requiring specified people
to approve a merge request before it can be merged.
Required approvals enable multiple use cases:
- Enforcing review of all code that gets merged into a repository.
- Specifying reviewers for a given proposed code change, as well as a minimum number
of reviewers, through [Approval rules](rules.md).
- Specifying categories of reviewers, such as backend, frontend, quality assurance,
database, and so on, for all proposed code changes.
- Designating [Code Owners as eligible approvers](rules.md#code-owners-as-eligible-approvers),
determined by the files changed in a merge request.
- [Requiring approval from a security team](../../../application_security/index.md#security-approvals-in-merge-requests)
before merging code that could introduce a vulnerability.**(ULTIMATE)**
### Adding or removing an approval
When an [eligible approver](rules.md#eligible-approvers) visits an open merge request,
one of the following is possible:
- If the required number of approvals has _not_ been yet met, they can approve
it by clicking the displayed **Approve** button.
![Approve](img/approve.png)
- If the required number of approvals has already been met, they can still
approve it by clicking the displayed **Approve additionally** button.
![Add approval](img/approve_additionally.png)
- **They have already approved this merge request**: They can remove their approval.
![Remove approval](img/remove_approval.png)
When [approval rule overrides](settings.md#prevent-overriding-default-approvals) are allowed,
changes to default approval rules will **not** be applied to existing
merge requests, except for changes to the [target branch](rules.md#scoped-to-protected-branch)
of the rule.
NOTE:
The merge request author is not allowed to approve their own merge request if
[**Prevent author approval**](settings.md#allowing-merge-request-authors-to-approve-their-own-merge-requests)
is enabled in the project settings.
After the approval rules have been met, the merge request can be merged if there is nothing
else blocking it. Note that the merge request could still be blocked by other conditions,
such as merge conflicts, [pending discussions](../../../discussions/index.md#only-allow-merge-requests-to-be-merged-if-all-threads-are-resolved),
or a [failed CI/CD pipeline](../merge_when_pipeline_succeeds.md).
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
doc/user/project/merge_requests/approvals/rules.md 0 → 100644
View file @ ab06cec8
---
stage: Create
group: Source Code
info: "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"
type: reference, concepts
---
# Merge request approval rules
Approval rules define how many approvals a merge request must receive before it can
be merged, and optionally which users should do the approving. Approvals can be defined:
- [As project defaults](#adding--editing-a-default-approval-rule).
- [Per merge request](#editing--overriding-approval-rules-per-merge-request).
If no approval rules are defined, any user can approve a merge request. However, the default
minimum number of required approvers can still be set in the
[settings for merge request approvals](settings.md).
You can opt to define one single rule to approve a merge request among the available rules
or choose more than one with [multiple approval rules](#multiple-approval-rules).
NOTE:
On GitLab.com, you can add a group as an approver if you're a member of that group or the
group is public.
## Eligible Approvers
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10294) in GitLab 13.3, when an eligible approver comments on a merge request, it appears in the **Commented by** column of the Approvals widget.
The following users can approve merge requests:
- Users who have been added as approvers at the project or merge request levels with
developer or higher [permissions](../../../permissions.md).
- [Code owners](#code-owners-as-eligible-approvers) of the files changed by the merge request
that have developer or higher [permissions](../../../permissions.md).
An individual user can be added as an approver for a project if they are a member of:
- The project.
- The project's immediate parent group.
- A group that has access to the project via a [share](../../members/share_project_with_groups.md).
A group of users can also be added as approvers, though they only count as approvers if
they have direct membership to the group. In the future, group approvers may be
[restricted to only groups with share access to the project](https://gitlab.com/gitlab-org/gitlab/-/issues/2048).
If a user is added as an individual approver and is also part of a group approver,
then that user is just counted once. The merge request author, and users who have committed
to the merge request, do not count as eligible approvers,
if [**Prevent author approval**](settings.md#allowing-merge-request-authors-to-approve-their-own-merge-requests) (enabled by default)
and [**Prevent committers approval**](settings.md#prevent-approval-of-merge-requests-by-their-committers) (disabled by default)
are enabled on the project settings.
When an eligible approver comments on a merge request, it displays in the
**Commented by** column of the Approvals widget. It indicates who participated in
the merge request review. Authors and reviewers can also identify who they should reach out
to if they have any questions about the content of the merge request.
### Implicit Approvers
If the number of required approvals is greater than the number of assigned approvers,
approvals from other users counts towards meeting the requirement. These would be
users with developer [permissions](../../../permissions.md) or higher in the project who
were not explicitly listed in the approval rules.
### Code Owners as eligible approvers
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7933) in GitLab 11.5.
> - Moved to GitLab Premium in 13.9.
If you add [Code Owners](../../code_owners.md) to your repository, the owners to the
corresponding files become eligible approvers, together with members with Developer
or higher [permissions](../../../permissions.md).
To enable this merge request approval rule:
1. Navigate to your project's **Settings > General** and expand
**Merge request (MR) approvals**.
1. Locate **Any eligible user** and choose the number of approvals required.
![MR approvals by Code Owners](img/mr_approvals_by_code_owners_v12_7.png)
Once set, merge requests can only be merged once approved by the
number of approvals you've set. GitLab accepts approvals from
users with Developer or higher permissions, as well as by Code Owners,
indistinguishably.
Alternatively, you can **require**
[Code Owner's approvals for protected branches](../../protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)**
## Merge Request approval segregation of duties
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40491) in GitLab 13.4.
> - Moved to Premium in 13.9.
Managers or operators with [Reporter permissions](../../../permissions.md#project-members-permissions)
to a project sometimes need to be required approvers of a merge request,
before a merge to a protected branch begins. These approvers aren't allowed
to push or merge code to any branches.
To enable this access:
1. [Create a new group](../../../group/index.md#create-a-group), and then
[add the user to the group](../../../group/index.md#add-users-to-a-group),
ensuring you select the Reporter role for the user.
1. [Share the project with your group](../../members/share_project_with_groups.md#sharing-a-project-with-a-group-of-users),
based on the Reporter role.
1. Navigate to your project's **Settings > General**, and in the
**Merge request (MR) approvals** section, click **Expand**.
1. Select **Add approval rule** or **Update approval rule**.
1. [Add the group](../../../group/index.md#create-a-group) to the permission list.
![Update approval rule](img/update_approval_rule_v13_10.png)
## Adding / editing a default approval rule
To add or edit the default merge request approval rule:
1. Navigate to your project's **Settings > General** and expand **Merge request (MR) approvals**.
1. Click **Add approval rule**, or **Edit**.
- Add or change the **Rule name**.
- Set the number of required approvals in **Approvals required**. The minimum value is `0`.
- (Optional) Search for users or groups that are [eligible to approve](#eligible-approvers)
merge requests and click the **Add** button to add them as approvers. Before typing
in the search field, approvers are suggested based on the previous authors of
the files being changed by the merge request.
- (Optional) Click the **{remove}** **Remove** button next to a group or user to delete it from
the rule.
1. Click **Add approval rule** or **Update approval rule**.
When [approval rule overrides](settings.md#prevent-overriding-default-approvals) are allowed,
changes to these default rules are not applied to existing merge
requests, except for changes to the [target branch](#scoped-to-protected-branch) of
the rule.
When approval rule overrides are not allowed, all changes to these default rules
are applied to existing merge requests. Any approval rules that had previously been
manually [overridden](#editing--overriding-approval-rules-per-merge-request) during a
period when approval rule overrides where allowed, are not modified.
NOTE:
If a merge request targets a different project, such as from a fork to the upstream project,
the default approval rules are taken from the target (upstream) project, not the
source (fork).
### Editing / overriding approval rules per merge request
> Introduced in GitLab Enterprise Edition 9.4.
By default, the merge request approval rule listed in each merge request (MR) can be
edited by the MR author or a user with sufficient [permissions](../../../permissions.md).
This ability can be disabled in the [merge request approvals settings](settings.md#prevent-overriding-default-approvals).
One possible scenario would be to add more approvers than were defined in the default
settings.
When creating or editing a merge request, find the **Approval rules** section, then follow
the same steps as [Adding / editing a default approval rule](#adding--editing-a-default-approval-rule).
## Set up an optional approval rule
MR approvals can be configured to be optional, which can help if you're working
on a team where approvals are appreciated, but not required.
To configure an approval to be optional, set the number of required approvals in **Approvals required** to `0`.
You can also set an optional approval rule through the [Merge requests approvals API](../../../../api/merge_request_approvals.md#update-merge-request-level-rule), by setting the `approvals_required` attribute to `0`.
## Multiple approval rules **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
In GitLab Premium, it is possible to have multiple approval rules per merge request,
as well as multiple default approval rules per project.
Adding or editing multiple default rules is identical to
[adding or editing a single default approval rule](#adding--editing-a-default-approval-rule),
except the **Add approval rule** button is available to add more rules, even after
a rule is already defined.
Similarly, editing or overriding multiple approval rules per merge request is identical
to [editing or overriding approval rules per merge request](#editing--overriding-approval-rules-per-merge-request),
except the **Add approval rule** button is available to add more rules, even after
a rule is already defined.
When an [eligible approver](#eligible-approvers) approves a merge request, it
reduces the number of approvals left for all rules that the approver belongs to.
![Approvals premium merge request widget](img/approvals_premium_mr_widget_v13_3.png)
## Scoped to protected branch **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/460) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.8.
Approval rules are often only relevant to specific branches, like `master`.
When configuring [**Default Approval Rules**](#adding--editing-a-default-approval-rule)
these can be scoped to all the protected branches at once by navigating to your project's
**Settings**, expanding **Merge request (MR) approvals**, and selecting **Any branch** from
the **Target branch** dropdown.
Alternatively, you can select a very specific protected branch from the **Target branch** dropdown:
![Scoped to protected branch](img/scoped_to_protected_branch_v13_10.png)
To enable this configuration, see [Code Owner's approvals for protected branches](../../protected_branches.md#protected-branches-approval-by-code-owners).
doc/user/project/merge_requests/approvals/settings.md 0 → 100644
View file @ ab06cec8
---
stage: Create
group: Source Code
info: "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"
type: reference, concepts
---
# Merge request approval settings
The settings for Merge Request Approvals are found by going to
**Settings > General** and expanding **Merge request (MR) approvals**.
## Prevent overriding default approvals
Regardless of the approval rules you choose for your project, users can edit them in every merge
request, overriding the [rules you set as default](rules.md#adding--editing-a-default-approval-rule).
To prevent that from happening:
1. Select the **Prevent users from modifying MR approval rules in merge requests.** checkbox.
1. Click **Save changes**.
### Resetting approvals on push
You can force all approvals on a merge request to be removed when new commits are
pushed to the source branch of the merge request. If disabled, approvals persist
even if there are changes added to the merge request. To enable this feature:
1. Check the **Require new approvals when new commits are added to an MR.**
checkbox.
1. Click **Save changes**.
NOTE:
Approvals do not get reset when [rebasing a merge request](../fast_forward_merge.md)
from the UI. However, approvals are reset if the target branch is changed.
### Allowing merge request authors to approve their own merge requests **(PREMIUM)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3349) in GitLab 11.3.
> - Moved to GitLab Premium in 13.9.
By default, projects are configured to prevent merge requests from being approved by
their own authors. To change this setting:
1. Go to your project's **Settings > General**, expand **Merge request (MR) approvals**.
1. Uncheck the **Prevent MR approval by the author.** checkbox.
1. Click **Save changes**.
Note that users can edit the approval rules in every merge request and override pre-defined settings unless it's set [**not to allow** overrides](#prevent-overriding-default-approvals).
You can prevent authors from approving their own merge requests
[at the instance level](../../../admin_area/merge_requests_approvals.md). When enabled,
this setting is disabled on the project level, and not editable.
### Prevent approval of merge requests by their committers **(PREMIUM)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10441) in GitLab 11.10.
> - Moved to GitLab Premium in 13.9.
You can prevent users who have committed to a merge request from approving it,
though code authors can still approve. You can enable this feature
[at the instance level](../../../admin_area/merge_requests_approvals.md), which
disables changes to this feature at the project level. If you prefer to manage
this feature at the project level, you can:
1. Check the **Prevent MR approvals from users who make commits to the MR.** checkbox.
If this check box is disabled, this feature has been disabled
[at the instance level](../../../admin_area/merge_requests_approvals.md).
1. Click **Save changes**.
Read the official Git documentation for an explanation of the
[differences between authors and committers](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History).
### Require authentication when approving a merge request
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5981) in GitLab 12.0.
> - Moved to GitLab Premium in 13.9.
NOTE:
To require authentication when approving a merge request, you must enable
**Password authentication enabled for web interface** under [sign-in restrictions](../../../admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
in the Admin Area.
You can force the approver to enter a password in order to authenticate before adding
the approval. This enables an Electronic Signature for approvals such as the one defined
by [CFR Part 11](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11&showFR=1&subpartNode=21:1.0.1.1.8.3)).
To enable this feature:
1. Check the **Require user password for approvals.** checkbox.
1. Click **Save changes**.
## Security approvals in merge requests **(ULTIMATE)**
Merge Request Approvals can be configured to require approval from a member
of your security team when a vulnerability would be introduced by a merge request.
For more information, see
[Security approvals in merge requests](../../../application_security/index.md#security-approvals-in-merge-requests).
doc/user/project/merge_requests/getting_started.md
View file @ ab06cec8
......@@ -56,7 +56,7 @@ request's page at the top-right side:
- [Assign](#assignee) the merge request to a colleague for review. With [multiple assignees](#multiple-assignees), you can assign it to more than one person at a time.
- Set a [milestone](../milestones/index.md) to track time-sensitive changes.
- Add [labels](../labels.md) to help contextualize and filter your merge requests over time.
- Require [approval](merge_request_approvals.md) from your team. **(PREMIUM)**
- [Require approval](approvals/index.md#required-approvals) from your team. **(PREMIUM)**
- [Close issues automatically](#merge-requests-to-close-issues) when they are merged.
- Enable the [delete source branch when merge request is accepted](#deleting-the-source-branch) option to keep your repository clean.
- Enable the [squash commits when merge request is accepted](squash_and_merge.md) option to combine all the commits into one before merging, thus keep a clean commit history in your repository.
......@@ -138,7 +138,7 @@ When selected, GitLab creates a [to-do list item](../../todos.md) for each revie
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/293742) in GitLab 13.9.
When editing the **Reviewers** field in a new or existing merge request, GitLab
displays the name of the matching [approval rule](merge_request_approvals.md#approval-rules)
displays the name of the matching [approval rule](approvals/rules.md)
below the name of each suggested reviewer. [Code Owners](../code_owners.md) are displayed as `Codeowner` without group detail.
This example shows reviewers and approval rules when creating a new merge request:
......
doc/user/project/merge_requests/index.md
View file @ ab06cec8
......@@ -29,10 +29,10 @@ For a software developer working in a team:
1. You work on the implementation optimizing code with [Code Quality reports](code_quality.md).
1. You verify your changes with [Unit test reports](../../../ci/unit_test_reports.md) in GitLab CI/CD.
1. You avoid using dependencies whose license is not compatible with your project with [License Compliance reports](../../compliance/license_compliance/index.md).
1. You request the [approval](merge_request_approvals.md) from your manager.
1. You request the [approval](approvals/index.md) from your manager.
1. Your manager:
1. Pushes a commit with their final review.
1. [Approves the merge request](merge_request_approvals.md).
1. [Approves the merge request](approvals/index.md).
1. Sets it to [merge when pipeline succeeds](merge_when_pipeline_succeeds.md).
1. Your changes get deployed to production with [manual actions](../../../ci/yaml/README.md#whenmanual) for GitLab CI/CD.
1. Your implementations were successfully shipped to your customer.
......@@ -43,7 +43,7 @@ For a web developer writing a webpage for your company's website:
1. You gather feedback from your reviewers.
1. You preview your changes with [Review Apps](../../../ci/review_apps/index.md).
1. You request your web designers for their implementation.
1. You request the [approval](merge_request_approvals.md) from your manager.
1. You request the [approval](approvals/index.md) from your manager.
1. Once approved, your merge request is [squashed and merged](squash_and_merge.md), and [deployed to staging with GitLab Pages](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/).
1. Your production team [cherry picks](cherry_pick_changes.md) the merge commit into production.
......
doc/user/project/merge_requests/merge_request_approvals.md
View file @ ab06cec8
---
stage: Create
group: Source Code
info: "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"
type: reference, concepts
redirect_to: 'approvals/index.md'
---
# Merge Request Approvals **(FREE)**
This document was moved to [another location](approvals/index.md).
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/580) in GitLab Enterprise Edition 7.2. Available in GitLab Free and higher tiers.
> - Redesign [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8 and [feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/10685) in 12.0.
Code review is an essential practice of every successful project. Approving a
merge request is an important part of the review
process, as it clearly communicates the ability to merge the change.
A [merge request approvals API](../../../api/merge_request_approvals.md) is also available.
## Optional Approvals
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27426) in GitLab 13.2.
Any user with Developer or greater [permissions](../../permissions.md) can approve a merge request in GitLab Free and higher tiers.
This provides a consistent mechanism for reviewers to approve merge requests, and ensures
maintainers know a change is ready to merge. Approvals in Free are optional, and do
not prevent a merge request from being merged when there is no approval.
## External approvals **(ULTIMATE)**
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3869) in GitLab Ultimate 13.10.
> - It's [deployed behind a feature flag](../../feature_flags.md), disabled by default.
> - It's disabled on GitLab.com.
> - It's not recommended for production use.
> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](../../../api/merge_request_approvals.md#enable-or-disable-external-project-level-mr-approvals). **(ULTIMATE SELF)**
WARNING:
This feature might not be available to you. Check the **version history** note above for details.
When you create an external approval rule, the following merge request actions sends information
about a merge request to a third party service:
- Create
- Change
- Close
This action enables use-cases such as:
- Integration with 3rd party workflow tools, such as [ServiceNow](https://www.servicenow.co.uk/).
- Integration with custom tools designed to approve merge requests from outside of GitLab.
You can find more information about use-cases, development timelines and the feature discovery in
the [External API approval rules epic](https://gitlab.com/groups/gitlab-org/-/epics/3869).
The intention for this feature is to allow those 3rd party tools to approve a merge request similarly to how users current do.
NOTE:
The lack of an external approval does not block the merging of a merge request.
You can modify external approval rules through the [REST API](../../../api/merge_request_approvals.md#external-project-level-mr-approvals).
## Required Approvals **(PREMIUM)**
> - [Introduced](https://about.gitlab.com/releases/2015/06/22/gitlab-7-12-released/#merge-request-approvers-ee-only) in GitLab Enterprise Edition 7.12.
> - Moved to GitLab Premium in 13.9.
Required approvals enable enforced code review by requiring specified people
to approve a merge request before it can be merged.
Required approvals enable multiple use cases:
- Enforcing review of all code that gets merged into a repository.
- Specifying reviewers for a given proposed code change, as well as a minimum number
of reviewers, through [Approval rules](#approval-rules).
- Specifying categories of reviewers, such as backend, frontend, quality assurance,
database, and so on, for all proposed code changes.
- Designating [Code Owners as eligible approvers](#code-owners-as-eligible-approvers),
determined by the files changed in a merge request.
- [Requiring approval from a security team](#security-approvals-in-merge-requests)
before merging code that could introduce a vulnerability.**(ULTIMATE)**
### Approval Rules
Approval rules define how many approvals a merge request must receive before it can
be merged, and optionally which users should do the approving. Approvals can be defined:
- [As project defaults](#adding--editing-a-default-approval-rule).
- [Per merge request](#editing--overriding-approval-rules-per-merge-request).
If no approval rules are defined, any user can approve a merge request. However, the default
minimum number of required approvers can still be set in the
[settings for merge request approvals](#approval-settings).
You can opt to define one single rule to approve a merge request among the available rules
or choose more than one with [multiple approval rules](#multiple-approval-rules).
NOTE:
On GitLab.com, you can add a group as an approver if you're a member of that group or the
group is public.
#### Eligible Approvers
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10294) in GitLab 13.3, when an eligible approver comments on a merge request, it appears in the **Commented by** column of the Approvals widget.
The following users can approve merge requests:
- Users who have been added as approvers at the project or merge request levels with
developer or higher [permissions](../../permissions.md).
- [Code owners](#code-owners-as-eligible-approvers) of the files changed by the merge request
that have developer or higher [permissions](../../permissions.md).
An individual user can be added as an approver for a project if they are a member of:
- The project.
- The project's immediate parent group.
- A group that has access to the project via a [share](../members/share_project_with_groups.md).
A group of users can also be added as approvers, though they only count as approvers if
they have direct membership to the group. In the future, group approvers may be
[restricted to only groups with share access to the project](https://gitlab.com/gitlab-org/gitlab/-/issues/2048).
If a user is added as an individual approver and is also part of a group approver,
then that user is just counted once. The merge request author, and users who have committed
to the merge request, do not count as eligible approvers,
if [**Prevent author approval**](#allowing-merge-request-authors-to-approve-their-own-merge-requests) (enabled by default)
and [**Prevent committers approval**](#prevent-approval-of-merge-requests-by-their-committers) (disabled by default)
are enabled on the project settings.
When an eligible approver comments on a merge request, it displays in the
**Commented by** column of the Approvals widget. It indicates who participated in
the merge request review. Authors and reviewers can also identify who they should reach out
to if they have any questions about the content of the merge request.
##### Implicit Approvers
If the number of required approvals is greater than the number of assigned approvers,
approvals from other users counts towards meeting the requirement. These would be
users with developer [permissions](../../permissions.md) or higher in the project who
were not explicitly listed in the approval rules.
##### Code Owners as eligible approvers
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7933) in GitLab 11.5.
> - Moved to GitLab Premium in 13.9.
If you add [Code Owners](../code_owners.md) to your repository, the owners to the
corresponding files become eligible approvers, together with members with Developer
or higher [permissions](../../permissions.md).
To enable this merge request approval rule:
1. Navigate to your project's **Settings > General** and expand
**Merge request (MR) approvals**.
1. Locate **Any eligible user** and choose the number of approvals required.
![MR approvals by Code Owners](img/mr_approvals_by_code_owners_v12_7.png)
Once set, merge requests can only be merged once approved by the
number of approvals you've set. GitLab accepts approvals from
users with Developer or higher permissions, as well as by Code Owners,
indistinguishably.
Alternatively, you can **require**
[Code Owner's approvals for protected branches](../protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)**
#### Merge Request approval segregation of duties
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40491) in GitLab 13.4.
> - Moved to Premium in 13.9.
Managers or operators with [Reporter permissions](../../permissions.md#project-members-permissions)
to a project sometimes need to be required approvers of a merge request,
before a merge to a protected branch begins. These approvers aren't allowed
to push or merge code to any branches.
To enable this access:
1. [Create a new group](../../group/index.md#create-a-group), and then
[add the user to the group](../../group/index.md#add-users-to-a-group),
ensuring you select the Reporter role for the user.
1. [Share the project with your group](../members/share_project_with_groups.md#sharing-a-project-with-a-group-of-users),
based on the Reporter role.
1. Navigate to your project's **Settings > General**, and in the
**Merge request (MR) approvals** section, click **Expand**.
1. Select **Add approval rule** or **Update approval rule**.
1. [Add the group](../../group/index.md#create-a-group) to the permission list.
![Update approval rule](img/update_approval_rule_v13_10.png)
#### Adding / editing a default approval rule
To add or edit the default merge request approval rule:
1. Navigate to your project's **Settings > General** and expand **Merge request (MR) approvals**.
1. Click **Add approval rule**, or **Edit**.
- Add or change the **Rule name**.
- Set the number of required approvals in **Approvals required**. The minimum value is `0`.
- (Optional) Search for users or groups that are [eligible to approve](#eligible-approvers)
merge requests and click the **Add** button to add them as approvers. Before typing
in the search field, approvers are suggested based on the previous authors of
the files being changed by the merge request.
- (Optional) Click the **{remove}** **Remove** button next to a group or user to delete it from
the rule.
1. Click **Add approval rule** or **Update approval rule**.
When [approval rule overrides](#prevent-overriding-default-approvals) are allowed,
changes to these default rules are not applied to existing merge
requests, except for changes to the [target branch](#scoped-to-protected-branch) of
the rule.
When approval rule overrides are not allowed, all changes to these default rules
are applied to existing merge requests. Any approval rules that had previously been
manually [overridden](#editing--overriding-approval-rules-per-merge-request) during a
period when approval rule overrides where allowed, are not modified.
NOTE:
If a merge request targets a different project, such as from a fork to the upstream project,
the default approval rules are taken from the target (upstream) project, not the
source (fork).
##### Editing / overriding approval rules per merge request
> Introduced in GitLab Enterprise Edition 9.4.
By default, the merge request approval rule listed in each merge request (MR) can be
edited by the MR author or a user with sufficient [permissions](../../permissions.md).
This ability can be disabled in the [merge request approvals settings](#prevent-overriding-default-approvals).
One possible scenario would be to add more approvers than were defined in the default
settings.
When creating or editing a merge request, find the **Approval rules** section, then follow
the same steps as [Adding / editing a default approval rule](#adding--editing-a-default-approval-rule).
#### Set up an optional approval rule
MR approvals can be configured to be optional, which can help if you're working
on a team where approvals are appreciated, but not required.
To configure an approval to be optional, set the number of required approvals in **Approvals required** to `0`.
You can also set an optional approval rule through the [Merge requests approvals API](../../../api/merge_request_approvals.md#update-merge-request-level-rule), by setting the `approvals_required` attribute to `0`.
#### Multiple approval rules **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
In GitLab Premium, it is possible to have multiple approval rules per merge request,
as well as multiple default approval rules per project.
Adding or editing multiple default rules is identical to
[adding or editing a single default approval rule](#adding--editing-a-default-approval-rule),
except the **Add approval rule** button is available to add more rules, even after
a rule is already defined.
Similarly, editing or overriding multiple approval rules per merge request is identical
to [editing or overriding approval rules per merge request](#editing--overriding-approval-rules-per-merge-request),
except the **Add approval rule** button is available to add more rules, even after
a rule is already defined.
When an [eligible approver](#eligible-approvers) approves a merge request, it
reduces the number of approvals left for all rules that the approver belongs to.
![Approvals premium merge request widget](img/approvals_premium_mr_widget_v13_3.png)
#### Scoped to protected branch **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/460) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.8.
Approval rules are often only relevant to specific branches, like `master`.
When configuring [**Default Approval Rules**](#adding--editing-a-default-approval-rule)
these can be scoped to all the protected branches at once by navigating to your project's
**Settings**, expanding **Merge request (MR) approvals**, and selecting **Any branch** from
the **Target branch** dropdown.
Alternatively, you can select a very specific protected branch from the **Target branch** dropdown:
![Scoped to protected branch](img/scoped_to_protected_branch_v13_10.png)
To enable this configuration, see [Code Owner's approvals for protected branches](../protected_branches.md#protected-branches-approval-by-code-owners).
### Adding or removing an approval
When an [eligible approver](#eligible-approvers) visits an open merge request,
one of the following is possible:
- If the required number of approvals has _not_ been yet met, they can approve
it by clicking the displayed **Approve** button.
![Approve](img/approve.png)
- If the required number of approvals has already been met, they can still
approve it by clicking the displayed **Approve additionally** button.
![Add approval](img/approve_additionally.png)
- **They have already approved this merge request**: They can remove their approval.
![Remove approval](img/remove_approval.png)
When [approval rule overrides](#prevent-overriding-default-approvals) are allowed,
changes to default approval rules will **not** be applied to existing
merge requests, except for changes to the [target branch](#scoped-to-protected-branch)
of the rule.
NOTE:
The merge request author is not allowed to approve their own merge request if
[**Prevent author approval**](#allowing-merge-request-authors-to-approve-their-own-merge-requests)
is enabled in the project settings.
After the approval rules have been met, the merge request can be merged if there is nothing
else blocking it. Note that the merge request could still be blocked by other conditions,
such as merge conflicts, [pending discussions](../../discussions/index.md#only-allow-merge-requests-to-be-merged-if-all-threads-are-resolved),
or a [failed CI/CD pipeline](merge_when_pipeline_succeeds.md).
### Approval settings
The settings for Merge Request Approvals are found by going to
**Settings > General** and expanding **Merge request (MR) approvals**.
#### Prevent overriding default approvals
Regardless of the approval rules you choose for your project, users can edit them in every merge
request, overriding the rules you set as [default](#adding--editing-a-default-approval-rule).
To prevent that from happening:
1. Select the **Prevent users from modifying MR approval rules in merge requests.** checkbox.
1. Click **Save changes**.
#### Resetting approvals on push
You can force all approvals on a merge request to be removed when new commits are
pushed to the source branch of the merge request. If disabled, approvals persist
even if there are changes added to the merge request. To enable this feature:
1. Check the **Require new approvals when new commits are added to an MR.**
checkbox.
1. Click **Save changes**.
NOTE:
Approvals do not get reset when [rebasing a merge request](fast_forward_merge.md)
from the UI. However, approvals are reset if the target branch is changed.
#### Allowing merge request authors to approve their own merge requests **(PREMIUM)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3349) in GitLab 11.3.
> - Moved to GitLab Premium in 13.9.
By default, projects are configured to prevent merge requests from being approved by
their own authors. To change this setting:
1. Go to your project's **Settings > General**, expand **Merge request (MR) approvals**.
1. Uncheck the **Prevent MR approval by the author.** checkbox.
1. Click **Save changes**.
Note that users can edit the approval rules in every merge request and override pre-defined settings unless it's set [**not to allow** overrides](#prevent-overriding-default-approvals).
You can prevent authors from approving their own merge requests
[at the instance level](../../admin_area/merge_requests_approvals.md). When enabled,
this setting is disabled on the project level, and not editable.
#### Prevent approval of merge requests by their committers **(PREMIUM)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10441) in GitLab 11.10.
> - Moved to GitLab Premium in 13.9.
You can prevent users who have committed to a merge request from approving it,
though code authors can still approve. You can enable this feature
[at the instance level](../../admin_area/merge_requests_approvals.md), which
disables changes to this feature at the project level. If you prefer to manage
this feature at the project level, you can:
1. Check the **Prevent MR approvals from users who make commits to the MR.** checkbox.
If this check box is disabled, this feature has been disabled
[at the instance level](../../admin_area/merge_requests_approvals.md).
1. Click **Save changes**.
Read the official Git documentation for an explanation of the
[differences between authors and committers](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History).
#### Require authentication when approving a merge request
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5981) in GitLab 12.0.
> - Moved to GitLab Premium in 13.9.
NOTE:
To require authentication when approving a merge request, you must enable
**Password authentication enabled for web interface** under [sign-in restrictions](../../admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
in the Admin Area.
You can force the approver to enter a password in order to authenticate before adding
the approval. This enables an Electronic Signature for approvals such as the one defined
by [CFR Part 11](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11&showFR=1&subpartNode=21:1.0.1.1.8.3)).
To enable this feature:
1. Check the **Require user password for approvals.** checkbox.
1. Click **Save changes**.
### Security approvals in merge requests **(ULTIMATE)**
Merge Request Approvals can be configured to require approval from a member
of your security team when a vulnerability would be introduced by a merge request.
For more information, see
[Security approvals in merge requests](../../application_security/index.md#security-approvals-in-merge-requests).
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
<!-- This redirect file can be deleted after <2021-07-27>. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
doc/user/project/repository/branches/index.md
View file @ ab06cec8
......@@ -19,7 +19,7 @@ After pushing your changes to a new branch, you can:
- [Discuss](../../../discussions/index.md) your implementation with your team
- Preview changes submitted to a new branch with [Review Apps](../../../../ci/review_apps/index.md).
You can also request [approval](../../merge_requests/merge_request_approvals.md)
You can also request [approval](../../merge_requests/approvals/index.md)
from your managers.
For more information on managing branches using the GitLab UI, see:
......
doc/user/project/settings/index.md
View file @ ab06cec8
......@@ -209,7 +209,7 @@ Set up your project's merge request settings:
- Set up the merge request method (merge commit, [fast-forward merge](../merge_requests/fast_forward_merge.md)).
- Add merge request [description templates](../description_templates.md#description-templates).
- Enable [merge request approvals](../merge_requests/merge_request_approvals.md).
- Enable [merge request approvals](../merge_requests/approvals/index.md).
- Enable [merge only if pipeline succeeds](../merge_requests/merge_when_pipeline_succeeds.md).
- Enable [merge only when all threads are resolved](../../discussions/index.md#only-allow-merge-requests-to-be-merged-if-all-threads-are-resolved).
- Enable [`delete source branch after merge` option by default](../merge_requests/getting_started.md#deleting-the-source-branch)
......
ee/app/views/projects/_merge_request_approvals_settings_form.html.haml
View file @ ab06cec8
......@@ -27,7 +27,7 @@
= form.check_box(:disable_overriding_approvers_per_merge_request, { class: 'custom-control-input', disabled: !can_modify_approvers })
= form.label :disable_overriding_approvers_per_merge_request, class: 'custom-control-label' do
%span= _('Prevent users from modifying MR approval rules in merge requests.')
= link_to sprite_icon('question-o'), help_page_path('user/project/merge_requests/merge_request_approvals', anchor: 'prevent-overriding-default-approvals'), target: '_blank'
= link_to sprite_icon('question-o'), help_page_path('user/project/merge_requests/approvals/settings', anchor: 'prevent-overriding-default-approvals'), target: '_blank'
.gl-form-checkbox.custom-control.custom-checkbox
= form.check_box :reset_approvals_on_push, class: 'custom-control-input'
......@@ -39,14 +39,14 @@
= form.label :merge_requests_author_approval, class: 'custom-control-label' do
%span= _('Prevent MR approvals by the author.')
= link_to sprite_icon('question-o'), help_page_path('user/project/merge_requests/merge_request_approvals',
= link_to sprite_icon('question-o'), help_page_path('user/project/merge_requests/approvals/settings',
anchor: 'allowing-merge-request-authors-to-approve-their-own-merge-requests'), target: '_blank'
.gl-form-checkbox.custom-control.custom-checkbox
= form.check_box :merge_requests_disable_committers_approval, { disabled: !can_modify_merge_request_committer_settings, class: 'custom-control-input' }
= form.label :merge_requests_disable_committers_approval, class: 'custom-control-label' do
%span= _('Prevent MR approvals from users who make commits to the MR.')
= link_to sprite_icon('question-o'), help_page_path('user/project/merge_requests/merge_request_approvals',
= link_to sprite_icon('question-o'), help_page_path('user/project/merge_requests/approvals/settings',
anchor: 'allowing-merge-request-authors-to-approve-their-own-merge-requests'), target: '_blank'
- if password_authentication_enabled_for_web?
......@@ -54,5 +54,5 @@
= form.check_box :require_password_to_approve, class: 'custom-control-input'
= form.label :require_password_to_approve, class: 'custom-control-label' do
%span= _('Require user password for approvals.')
= link_to sprite_icon('question-o'), help_page_path('user/project/merge_requests/merge_request_approvals',
= link_to sprite_icon('question-o'), help_page_path('user/project/merge_requests/approvals/settings',
anchor: 'require-authentication-when-approving-a-merge-request'), target: '_blank'
ee/app/views/shared/issuable/_approver_suggestion.haml
View file @ ab06cec8
......@@ -13,7 +13,7 @@
'can-override': @target_project.can_override_approvers?.to_s,
'mr_id': issuable.iid,
'mr_settings_path': presenter.api_approval_settings_path,
'eligible_approvers_docs_path': help_page_path('user/project/merge_requests/merge_request_approvals', anchor: 'eligible-approvers'),
'eligible_approvers_docs_path': help_page_path('user/project/merge_requests/approvals/rules', anchor: 'eligible-approvers'),
'project_settings_path': presenter.api_project_approval_settings_path } }
= sprite_icon('spinner', size: 24, css_class: 'gl-spinner')
- if can_update_approvers && show_code_owner_tip && Feature.disabled?(:mr_collapsed_approval_rules, @project, default_enabled: :yaml)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7