Commit 4c9d60c1 authored by GitLab Bot's avatar GitLab Bot

Add latest changes from gitlab-org/gitlab@master

parent 79216161
...@@ -956,7 +956,7 @@ POST /projects/:id/merge_requests/:merge_request_iid/approve ...@@ -956,7 +956,7 @@ POST /projects/:id/merge_requests/:merge_request_iid/approve
| `id` | integer | yes | The ID of a project | | `id` | integer | yes | The ID of a project |
| `merge_request_iid` | integer | yes | The IID of MR | | `merge_request_iid` | integer | yes | The IID of MR |
| `sha` | string | no | The HEAD of the MR | | `sha` | string | no | The HEAD of the MR |
| `approval_password` **(STARTER)** | 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-starter) is enabled in the project settings. | | `approval_password` **(STARTER)** | 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. |
The `sha` parameter works in the same way as 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 when [accepting a merge request](merge_requests.md#accept-mr): if it is passed, then it must
......
...@@ -59,8 +59,7 @@ integrity is guaranteed. ...@@ -59,8 +59,7 @@ integrity is guaranteed.
## Background migrations for EE-only features ## Background migrations for EE-only features
All the background migration classes for EE-only features should be present in GitLab CE. All the background migration classes for EE-only features should be present in GitLab CE.
For this purpose, an empty class can be created for GitLab CE and for GitLab EE it can be extended For this purpose, an empty class can be created for GitLab CE, and it can be extended for GitLab EE
For this purpose, an empty class can be created for GitLab CE, and it can be extended for GitLab EE
as explained in the [guidelines for implementing Enterprise Edition features](ee_features.md#code-in-libgitlabbackground_migration). as explained in the [guidelines for implementing Enterprise Edition features](ee_features.md#code-in-libgitlabbackground_migration).
## How It Works ## How It Works
......
...@@ -148,12 +148,15 @@ Clicking on this button will create a merge request to apply the solution onto t ...@@ -148,12 +148,15 @@ Clicking on this button will create a merge request to apply the solution onto t
![Create merge request from vulnerability](img/create_issue_with_list_hover.png) ![Create merge request from vulnerability](img/create_issue_with_list_hover.png)
## Security approvals in merge requests **(ULTIMATE)** ## Security approvals in merge requests
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9928) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.2. > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9928) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.2.
Merge Request Approvals can be configured to require approval from a member Merge Request Approvals can be configured to require approval from a member of your
of your security team when a vulnerability, or a software license compliance violation would be introduced by a merge request. security team when a merge request would introduce one of the following security issues:
- a security vulnerability
- a software license compliance violation
This threshold is defined as `high`, `critical`, or `unknown` This threshold is defined as `high`, `critical`, or `unknown`
severity. When any vulnerabilities are present within a merge request, an severity. When any vulnerabilities are present within a merge request, an
......
...@@ -15,7 +15,7 @@ the last 30 days, averaged over the number of active users in that time period. ...@@ -15,7 +15,7 @@ the last 30 days, averaged over the number of active users in that time period.
provides a Lead score per feature, which is calculated based on GitLab's analysis provides a Lead score per feature, which is calculated based on GitLab's analysis
of top-performing instances based on [usage ping data](../admin_area/settings/usage_statistics.md#usage-ping-core-only) that GitLab has of top-performing instances based on [usage ping data](../admin_area/settings/usage_statistics.md#usage-ping-core-only) that GitLab has
collected. Your score is compared to the lead score of each feature and then expressed as a percentage at the bottom of said feature. collected. Your score is compared to the lead score of each feature and then expressed as a percentage at the bottom of said feature.
Your overall index score is an average of all your feature score percentages - this percentage value is presented above all the of features on the page. Your overall **index score** is an average of your feature scores. You can use this score to compare your DevOps status to other organizations.
![DevOps Score](img/dev_ops_score_v12_6.png) ![DevOps Score](img/dev_ops_score_v12_6.png)
......
...@@ -33,7 +33,7 @@ the given file. ...@@ -33,7 +33,7 @@ the given file.
Once you've set Code Owners to a project, you can configure it to Once you've set Code Owners to a project, you can configure it to
receive approvals: receive approvals:
- As [merge request eligible approvers](merge_requests/merge_request_approvals.md#code-owners-as-eligible-approvers-starter). **(STARTER)** - As [merge request eligible approvers](merge_requests/merge_request_approvals.md#code-owners-as-eligible-approvers).
- As required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners-premium). **(PREMIUM)** - As required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners-premium). **(PREMIUM)**
Once set, Code Owners are displayed in merge requests widgets: Once set, Code Owners are displayed in merge requests widgets:
......
...@@ -7,101 +7,37 @@ type: reference, concepts ...@@ -7,101 +7,37 @@ type: reference, concepts
> Introduced in [GitLab Enterprise Edition 7.12](https://about.gitlab.com/blog/2015/06/22/gitlab-7-12-released/#merge-request-approvers-ee-only). > Introduced in [GitLab Enterprise Edition 7.12](https://about.gitlab.com/blog/2015/06/22/gitlab-7-12-released/#merge-request-approvers-ee-only).
Merge request approvals enable enforced code review by requiring specified people Merge request approvals enable enforced code review by requiring specified people
to approve a merge request before it can be unblocked for merging. to approve a merge request before it can be merged.
## Use cases Merge request approvals enable multiple use cases:
1. Enforcing review of all code that gets merged into a repository. - Enforcing review of all code that gets merged into a repository.
1. Specifying code maintainers for an entire repository. - Specifying reviewers for a given proposed code change, as well as a minimum number
1. Specifying reviewers for a given proposed code change. of reviewers, through [Approval rules](#approval-rules)
1. Specifying categories of reviewers, such as BE, FE, QA, DB, etc., for all proposed code changes. - Specifying categories of reviewers, such as backend, frontend, quality assurance,
database, etc., for all proposed code changes.
- Automatically 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-ultimate)
before merging code that could introduce a vulnerability.**(ULTIMATE)**
## Enabling the new approvals interface ## Approval rules
NOTE: **Note:**
Prior to 12.0, if you are running a self-managed instance, the new interface shown on
this page will not be available unless the feature flag
`approval_rules` is enabled, which can be done from the Rails console by
instance administrators.
Use these commands to start the Rails console:
```sh
# Omnibus GitLab
gitlab-rails console
# Installation from source
cd /home/git/gitlab
sudo -u git -H bin/rails console RAILS_ENV=production
```
Then run `Feature.enable(:approval_rules)` to enable the feature flag.
## Editing approvals
To edit the merge request approvals:
1. Navigate to your project's **Settings > General** and expand
**Merge request approvals**.
![Approvals starter project empty](img/approvals_starter_project_empty.png)
1. Click **Edit**.
1. Search for users or groups that will be [eligible to approve](#eligible-approvers)
merge requests and click the **Add** button to add them as approvers. Note: selecting
approvers is optional.
1. Set the minimum number of required approvals under the **No. approvals required**
box. Note: the minimum can be 0.
1. Click **Update approvers**.
![Approvals starter project edit](img/approvals_starter_project_edit.png)
The steps above are the minimum required to get approvals working in your
merge requests, but there are a couple more options available that might be
suitable to your workflow:
- Choose whether the default settings can be Approval rules define how many approvals a merge request must receive before it can
[overridden per merge request](#overriding-the-merge-request-approvals-default-settings) be merged, and optionally which users should do the approving. This can be defined:
- Choose whether [approvals will be reset with new pushed commits](#resetting-approvals-on-push)
## Editing approvals **(PREMIUM)** - [As project defaults](#adding--editing-a-default-approval-rule)
- [Per merge request](#editing--overriding-approval-rules-per-merge-request)
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10. If no approval rules are defined, any user can approve a merge request, though the default
minimum number of required approvers can still be set in the [project settings for merge request approvals](#merge-request-approvals-project-settings).
For GitLab Premium, [multiple approver rules](#multiple-approval-rules-premium) can be configured. To configure the merge
request approval rules:
1. Navigate to your project's **Settings > General** and expand **Merge request approvals**.
1. Click **Add approvers** to create a new approval rule.
1. Just like in [GitLab Starter](#editing-approvals), select the approval members and approvals required.
1. Give the approval rule a name that describes the set of approvers selected.
1. Click **Add approval rule** to submit the new rule.
![Approvals premium project edit](img/approvals_premium_project_edit_v12_5.png)
## Multiple approval rules **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10. ### Eligible approvers
For GitLab Premium, a merge request's overall approval status is determined by a set of rules. Each rule contains:
- A set of [eligible approvers](#eligible-approvers).
- A minimum number of approvals required.
When an [eligible approver](#eligible-approvers) approves a merge request, it will reduce the number of approvals left for
all rules that the approver belongs to.
![Approvals premium merge request widget](img/approvals_premium_mr_widget.png)
If no approval rules are set, then the overall minimum number of approvals required can be configured. With no approval rules,
any [eligible approver](#eligible-approvers) may approve.
## Eligible approvers
The following can approve merge requests: The following can approve merge requests:
- Users being added as approvers at project or merge request level. - Users being added as approvers at project or merge request level.
- [Code owners](#code-owners-as-eligible-approvers-starter) to the files changed by the merge request. - [Code owners](#code-owners-as-eligible-approvers) to the files changed by the merge request.
An individual user can be added as an approver for a project if they are a member of: An individual user can be added as an approver for a project if they are a member of:
...@@ -109,8 +45,8 @@ An individual user can be added as an approver for a project if they are a membe ...@@ -109,8 +45,8 @@ An individual user can be added as an approver for a project if they are a membe
- The project's immediate parent group. - 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 that has access to the project via a [share](../members/share_project_with_groups.md).
A group can also be added as an approver. [In the future](https://gitlab.com/gitlab-org/gitlab/issues/2048), A group of users can also be added as approvers. In the future, group approvers may be
group approvers will be restricted. [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, 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, as well as users who have committed then that user is just counted once. The merge request author, as well as users who have committed
...@@ -119,19 +55,25 @@ if [**Prevent author approval**](#allowing-merge-request-authors-to-approve-thei ...@@ -119,19 +55,25 @@ if [**Prevent author approval**](#allowing-merge-request-authors-to-approve-thei
and [**Prevent committers approval**](#prevent-approval-of-merge-requests-by-their-committers) (disabled by default) and [**Prevent committers approval**](#prevent-approval-of-merge-requests-by-their-committers) (disabled by default)
are enabled on the project settings. are enabled on the project settings.
### Code Owners as eligible approvers **(STARTER)** #### Implicit approvers
If the number of required approvals is greater than the number of assigned approvers,
approvals from other users will count 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 Starter](https://about.gitlab.com/pricing/) 11.5. > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/7933) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.5.
Once you've added [Code Owners](../code_owners.md) to your If you add [Code Owners](../code_owners.md) to your repository, the owners to the
repository, the owners to the corresponding files will become corresponding files will become eligible approvers, together with members with Developer
eligible approvers, together with members with Developer or or higher permissions.
higher permissions.
To enable this merge request approval rule: To enable this merge request approval rule:
1. Navigate to your project's **Settings > General** and expand 1. Navigate to your project's **Settings > General** and expand
**Merge request approvals**. **Merge request approvals**.
1. Locate **All members with Developer role or higher and code owners (if any)** and click **Edit** to choose the number of approvals required. 1. Locate **All members with Developer role or higher and code owners (if any)** and click **Edit** to choose the number of approvals required.
![MR approvals by Code Owners](img/mr_approvals_by_code_owners_v12_4.png) ![MR approvals by Code Owners](img/mr_approvals_by_code_owners_v12_4.png)
...@@ -144,205 +86,185 @@ indistinguishably. ...@@ -144,205 +86,185 @@ indistinguishably.
Alternatively, you can **require** Alternatively, you can **require**
[Code Owner's approvals for Protected Branches](../protected_branches.md#protected-branches-approval-by-code-owners-premium). **(PREMIUM)** [Code Owner's approvals for Protected Branches](../protected_branches.md#protected-branches-approval-by-code-owners-premium). **(PREMIUM)**
### Implicit approvers ### Adding / editing a default approval rule
If the number of required approvals is greater than the number of approvers, To add or edit the default merge request approval rule:
other users will become implicit approvers to fill the gap.
Those implicit approvers include members of the given project with Developer role or higher.
## Adding or removing an approval 1. Navigate to your project's **Settings > General** and expand **Merge request approvals**.
If approvals are activated for the given project, when a user visits an open 1. Click **Add approval rule**, or **Edit**.
merge request, depending on their [eligibility](#eligible-approvers), one of - Add or change the **Rule name**.
the following is possible: - Set the number of required approvals in **No. approvals required**. The minimum value is `0`.
- (Optional) Search for users or groups that will be [eligible to approve](#eligible-approvers)
merge requests and click the **Add** button to add them as approvers. Before typing
in the search field, approvers will be suggested based on the previous authors of
the files being changed by the merge request.
- (Optional) Click the **"trashcan"** button next to a group or user to delete it from
the rule.
1. Click **Add approval rule** or **Update approval rule**.
- **They are not an eligible approver**: They cannot do anything with respect Any merge requests that were created before changing the rules will not be changed.
to approving this merge request. They will keep the original approval rules, unless manually [overridden](#editing--overriding-approval-rules-per-merge-request).
- **They have not approved this merge request**: NOTE: **Note:**
If a merge request targets a different project, such as from a fork to the upstream project,
the default approval rules will be taken from the target (upstream) project, not the
source (fork).
- If the required number of approvals has _not_ been yet met, they can approve #### Editing / overriding approval rules per merge request
it by clicking the displayed **Approve** button.
![Approve](img/approve.png) > Introduced in GitLab Enterprise Edition 9.4.
- If the required number of approvals has already been met, they can still By default, the merge request approval rule listed in each merge request (MR) can be
approve it by clicking the displayed **Approve additionally** button. 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).
![Add approval](img/approve_additionally.png) One possible scenario would be to add more approvers than were defined in the default
settings.
- **They have already approved this merge request**: They can remove their approval. 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).
![Remove approval](img/remove_approval.png) ### Multiple approval rules **(PREMIUM)**
NOTE: **Note:** > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
The merge request author is only allowed to approve their own merge request
if [**Prevent author approval**](#allowing-merge-request-authors-to-approve-their-own-merge-requests) is disabled on the project settings.
For a given merge request, if the approval restrictions have been satisfied,
the merge request is unblocked and can be merged.
Note that meeting the required number of approvals is a necessary, but not
sufficient condition for unblocking a merge request from being merged. There
are other conditions that may block it, 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).
## Overriding the merge request approvals default settings In GitLab Premium, it is possible to have multiple approval rules per merge request,
as well as multiple default approval rules per project.
> Introduced in GitLab Enterprise Edition 9.4. 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 will be available to add more rules, even after
a rule is already defined.
NOTE: **Note:** Similarly, editing or overriding multiple approval rules per merge request is identical
If you are using GitLab Premium, things are a little different with [multiple approval rules](#multiple-approval-rules-premium). to [editing or overriding approval rules per merge request](#editing--overriding-approval-rules-per-merge-request),
Read the differences [in GitLab Premium when overriding merge request approvals](#overriding-merge-request-approvals-default-settings-premium). except the **Add approval rule** button will be available to add more rules, even after
a rule is already defined.
When an [eligible approver](#eligible-approvers) approves a merge request, it will
reduce the number of approvals left for all rules that the approver belongs to.
If approvals are [set at the project level](#editing-approvals), the ![Approvals premium merge request widget](img/approvals_premium_mr_widget.png)
default configuration (number of required approvals and approvers) can be
overridden for each merge request in that project.
One possible scenario would be to assign a group of approvers at the project ## Adding or removing an approval
level and change them later when creating or editing the merge request.
First, you have to enable this option in the project's settings: When an [eligible approver](#eligible-approvers) visits an open merge request,
one of the following is possible:
1. Navigate to your project's **Settings > General** and expand - If the required number of approvals has _not_ been yet met, they can approve
**Merge request approvals** it by clicking the displayed **Approve** button.
1. Tick the "Can override approvers and approvals required per merge request"
checkbox
![Approvals can override](img/approvals_can_override.png) ![Approve](img/approve.png)
1. Click **Save changes** - If the required number of approvals has already been met, they can still
approve it by clicking the displayed **Approve additionally** button.
NOTE: **Note:** ![Add approval](img/approve_additionally.png)
If approver overriding is enabled
and the project level approvers are changed after a merge request is created, - **They have already approved this merge request**: They can remove their approval.
the merge request retains the previous approvers.
However, the approvers can be changed by [editing the merge request](#overriding-the-merge-request-approvals-default-settings). ![Remove approval](img/remove_approval.png)
The default approval settings can now be overridden when creating a
[merge request](index.md) or by editing it after it's been created:
1. Click **Edit** under the **Approvers** section.
1. Search for users or groups that will be [eligible to approve](#eligible-approvers)
merge requests and click the **Add** button to add them as approvers or
remove existing approvers that were set in the project's settings.
1. If you want to change the number of required approvals, set a new number
in the **No. approvals required** box.
1. Click **Update approvers**.
NOTE: **Note:** NOTE: **Note:**
If you are contributing to a forked project, things are a little different. The merge request author is not allowed to approve their own merge request if
Read what happens when the [**Prevent author approval**](#allowing-merge-request-authors-to-approve-their-own-merge-requests)
[source and target branches are not the same](#merge-requests-with-different-source-branch-and-target-branch-projects). is enabled in the project settings.
## Overriding merge request approvals default settings **(PREMIUM)** Once 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).
In GitLab Premium, when the approval rules are [set at the project level](#editing-approvals-premium), ## Merge request approvals project settings
and **Can override approvers and approvals required per merge request** is checked,
approval rules can be added to an MR with no restriction.
## Resetting approvals on push The project settings for Merge request approvals are found by going to
**Settings > General** and expanding **Merge request approvals**.
If approvals are [set at the project level](#editing-approvals), ### Prevent overriding default approvals
you can choose whether all approvals on a merge request are removed when
new commits are pushed to the source branch of the merge request:
1. Navigate to your project's **Settings > General** and expand By default, users are able to edit the approval rules in merge requests. If disabled,
**Merge request approvals** the approval rules for all new merge requests will be determined by the
1. Tick the "Remove all approvals in a merge request when new commits are pushed to its source branch" [default approval rules](#adding--editing-a-default-approval-rule). To disable this feature:
checkbox
![Approvals remove on push](img/approvals_remove_on_push.png) 1. Uncheck the **Can override approvers and approvals required per merge request** 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 will persist
even if there are changes added to the merge request. To enable this feature:
1. Check the **Remove all approvals in a merge request when new commits are pushed to its source branch**
checkbox.
1. Click **Save changes** 1. Click **Save changes**
NOTE: **Note:** NOTE: **Note:**
Approvals do not get reset when [rebasing a merge request](fast_forward_merge.md) Approvals do not get reset when [rebasing a merge request](fast_forward_merge.md)
from the UI. from the UI. However, approvals will be reset if the target branch is changed.
However, approvals will be reset if the target branch is changed.
If you want approvals to persist, independent of changes to the merge request,
turn this setting to off by unchecking the box and saving the changes.
## Allowing merge request authors to approve their own merge requests ### Allowing merge request authors to approve their own merge requests
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/3349) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.3. > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/3349) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.3.
You can allow merge request authors to self-approve merge requests by You can allow merge request authors to self-approve merge requests. Authors
enabling it [at the project level](#editing-approvals). Authors
also need to be included in the approvers list in order to be able to also need to be included in the approvers list in order to be able to
approve their merge request. approve their merge request. To enable this feature:
1. Navigate to your project's **Settings > General** and expand **Merge request approvals**. 1. Uncheck the **Prevent approval of merge requests by merge request author** checkbox,
1. Uncheck the **Prevent approval of merge requests by merge request author** checkbox, which is enabled by default. which is enabled by default.
1. Click **Save changes**. 1. Click **Save changes**.
## Prevent approval of merge requests by their committers ### Prevent approval of merge requests by their committers
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/10441) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.10. > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/10441) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.10.
You can prevent users that have committed to a merge request from approving it by You can prevent users that have committed to a merge request from approving it. To
enabling [**Prevent approval of merge requests by their committers**](#prevent-approval-of-merge-requests-by-their-committers). enable this feature:
1. Navigate to your project's **Settings > General** and expand **Merge request approvals**. 1. Check the **Prevent approval of merge requests by their committers** checkbox.
1. Tick the checkbox **Prevent approval of merge requests by their committers**.
1. Click **Save changes**. 1. Click **Save changes**.
## Require authentication when approving a merge request **(STARTER)** ### Require authentication when approving a merge request
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5981) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.0. > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5981) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.0.
You can force the approver to enter a password in order to authenticate who is approving the merge request by You can force the approver to enter a password in order to authenticate before adding
enabling **Require user password to approve**. This enables an Electronic Signature the approval. This enables an Electronic Signature for approvals such as the one defined
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)): 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. Navigate to your project's **Settings > General** and expand **Merge request approvals**. 1. Check the **Require user password to approve** checkbox.
1. Tick the checkbox **Require user password to approve**.
1. Click **Save changes**. 1. Click **Save changes**.
## Merge requests with different source branch and target branch projects
If the merge request source branch and target branch belong to different
projects (which happens in merge requests in forked projects), everything is
with respect to the target branch's project (typically the original project).
In particular, since the merge request in this case is part of the target
branch's project, the relevant settings are the target project's. The source
branch's project settings are not applicable. Even if you start the merge
request from the source branch's project UI, pay attention to the created merge
request itself. It belongs to the target branch's project.
## Approver suggestions
Approvers are suggested for merge requests based on the previous authors of the files affected by the merge request.
## Filtering merge requests by approvers
> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/9468) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.9.
To filter merge requests by an individual approver, you can type (or select from
the dropdown) `approver` and select the user.
![Filter MRs by an approver](img/filter_approver_merge_requests.png)
## Security approvals in merge requests **(ULTIMATE)** ## Security approvals in merge requests **(ULTIMATE)**
> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.2.
Merge Request Approvals can be configured to require approval from a member 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. of your security team when a vulnerability would be introduced by a merge request.
For more information, see For more information, see
[Security approvals in merge requests](../../application_security/index.md#security-approvals-in-merge-requests-ultimate). [Security approvals in merge requests](../../application_security/index.md#security-approvals-in-merge-requests).
## Enabling the new approvals interface
## License compliance approvals in merge requests **(ULTIMATE)** Since [GitLab v12.0](https://gitlab.com/gitlab-org/gitlab/issues/10685), an updated approvals
interface is available by default. In versions older than 12.0, the updated interface is not
available unless the `approval_rules` feature flag is enabled, which can be done from
the Rails console by instance administrators.
> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.3. Use these commands to start the Rails console:
Merge Request Approvals can be configured to require approval from a member ```shell
of your security team when a blacklisted software license would be introduced by a merge request. # Omnibus GitLab
gitlab-rails console
For more information, see # Installation from source
[Security approvals in merge requests](../../application_security/index.md#security-approvals-in-merge-requests-ultimate). cd /home/git/gitlab
sudo -u git -H bin/rails console RAILS_ENV=production
```
Then run `Feature.enable(:approval_rules)` to enable the updated interface.
<!-- ## Troubleshooting <!-- ## Troubleshooting
......
...@@ -73,6 +73,15 @@ You can filter issues and merge requests by specific terms included in titles or ...@@ -73,6 +73,15 @@ You can filter issues and merge requests by specific terms included in titles or
![filter issues by specific terms](img/issue_search_by_term.png) ![filter issues by specific terms](img/issue_search_by_term.png)
### Filtering merge requests by approvers **(STARTER)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/9468) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.9.
To filter merge requests by an individual approver, you can type (or select from
the dropdown) `approver` and select the user.
![Filter MRs by an approver](img/filter_approver_merge_requests.png)
## Search history ## Search history
You can view recent searches by clicking on the little arrow-clock icon, which is to the left of the search input. Click the search entry to run that search again. This feature is available for issues and merge requests. Searches are stored locally in your browser. You can view recent searches by clicking on the little arrow-clock icon, which is to the left of the search input. Click the search entry to run that search again. This feature is available for issues and merge requests. Searches are stored locally in your browser.
......
...@@ -3,33 +3,14 @@ ...@@ -3,33 +3,14 @@
module QA module QA
module Resource module Resource
class ProjectMilestone < Base class ProjectMilestone < Base
attr_reader :title attribute :title
attr_accessor :description
attribute :project do attribute :project do
Project.fabricate! Project.fabricate!
end end
def title=(title) def initialize
@title = "#{title}-#{SecureRandom.hex(4)}" @title = "project-milestone-#{SecureRandom.hex(4)}"
@description = 'A milestone'
end
def fabricate!
project.visit!
Page::Project::Menu.perform do |menu|
menu.click_issues
menu.click_milestones
end
Page::Project::Milestone::Index.perform(&:click_new_milestone)
Page::Project::Milestone::New.perform do |milestone_new|
milestone_new.set_title(@title)
milestone_new.set_description(@description)
milestone_new.click_milestone_create_button
end
end end
def api_get_path def api_get_path
...@@ -42,8 +23,7 @@ module QA ...@@ -42,8 +23,7 @@ module QA
def api_post_body def api_post_body
{ {
description: @description, title: title
title: @title
} }
end end
end end
......
...@@ -32,7 +32,6 @@ module QA ...@@ -32,7 +32,6 @@ module QA
milestone = Resource::ProjectMilestone.fabricate_via_api! do |milestone| milestone = Resource::ProjectMilestone.fabricate_via_api! do |milestone|
milestone.project = @project milestone.project = @project
milestone.title = 'milestone'
end end
label = Resource::Label.fabricate_via_api! do |label| label = Resource::Label.fabricate_via_api! do |label|
......
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