Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2020-01-29 03:08:38 +00:00
parent 79216161b3
commit 4c9d60c166
14 changed files with 177 additions and 265 deletions

View file

@ -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

View file

@ -59,7 +59,6 @@ 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).

View file

@ -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

View file

@ -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)

View 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:

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.5 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.4 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 17 KiB

View file

@ -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:** Approval rules define how many approvals a merge request must receive before it can
Prior to 12.0, if you are running a self-managed instance, the new interface shown on be merged, and optionally which users should do the approving. This can be defined:
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: - [As project defaults](#adding--editing-a-default-approval-rule)
- [Per merge request](#editing--overriding-approval-rules-per-merge-request)
```sh If no approval rules are defined, any user can approve a merge request, though the default
# Omnibus GitLab minimum number of required approvers can still be set in the [project settings for merge request approvals](#merge-request-approvals-project-settings).
gitlab-rails console
# Installation from source ### Eligible approvers
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
[overridden per merge request](#overriding-the-merge-request-approvals-default-settings)
- Choose whether [approvals will be reset with new pushed commits](#resetting-approvals-on-push)
## Editing approvals **(PREMIUM)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
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.
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
- 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
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,29 +86,78 @@ 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. 1. Navigate to your project's **Settings > General** and expand **Merge request approvals**.
1. Click **Add approval rule**, or **Edit**.
- Add or change the **Rule name**.
- 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**.
Any merge requests that were created before changing the rules will not be changed.
They will keep the original approval rules, unless manually [overridden](#editing--overriding-approval-rules-per-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).
#### 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).
### 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 will be 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 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.
![Approvals premium merge request widget](img/approvals_premium_mr_widget.png)
## Adding or removing an approval ## Adding or removing an approval
If approvals are activated for the given project, when a user visits an open When an [eligible approver](#eligible-approvers) visits an open merge request,
merge request, depending on their [eligibility](#eligible-approvers), one of one of the following is possible:
the following is possible:
- **They are not an eligible approver**: They cannot do anything with respect - If the required number of approvals has _not_ been yet met, they can approve
to approving this merge request.
- **They have not approved this merge request**:
- If the required number of approvals has _not_ been yet met, they can approve
it by clicking the displayed **Approve** button. it by clicking the displayed **Approve** button.
![Approve](img/approve.png) ![Approve](img/approve.png)
- If the required number of approvals has already been met, they can still - If the required number of approvals has already been met, they can still
approve it by clicking the displayed **Approve additionally** button. approve it by clicking the displayed **Approve additionally** button.
![Add approval](img/approve_additionally.png) ![Add approval](img/approve_additionally.png)
@ -176,173 +167,104 @@ the following is possible:
![Remove approval](img/remove_approval.png) ![Remove approval](img/remove_approval.png)
NOTE: **Note:** NOTE: **Note:**
The merge request author is only allowed to approve their own merge request The merge request author is not allowed to approve their own merge request if
if [**Prevent author approval**](#allowing-merge-request-authors-to-approve-their-own-merge-requests) is disabled on the project settings. [**Prevent author approval**](#allowing-merge-request-authors-to-approve-their-own-merge-requests)
is enabled in the project settings.
For a given merge request, if the approval restrictions have been satisfied, Once the approval rules have been met, the merge request can be merged if there is nothing
the merge request is unblocked and can be merged. else blocking it. Note that the merge request could still be blocked by other conditions,
Note that meeting the required number of approvals is a necessary, but not such as merge conflicts, [pending discussions](../../discussions/index.md#only-allow-merge-requests-to-be-merged-if-all-threads-are-resolved),
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). or a [failed CI/CD pipeline](merge_when_pipeline_succeeds.md).
## Overriding the merge request approvals default settings ## Merge request approvals project settings
> Introduced in GitLab Enterprise Edition 9.4. The project settings for Merge request approvals are found by going to
**Settings > General** and expanding **Merge request approvals**.
NOTE: **Note:** ### Prevent overriding default approvals
If you are using GitLab Premium, things are a little different with [multiple approval rules](#multiple-approval-rules-premium).
Read the differences [in GitLab Premium when overriding merge request approvals](#overriding-merge-request-approvals-default-settings-premium).
If approvals are [set at the project level](#editing-approvals), the By default, users are able to edit the approval rules in merge requests. If disabled,
default configuration (number of required approvals and approvers) can be the approval rules for all new merge requests will be determined by the
overridden for each merge request in that project. [default approval rules](#adding--editing-a-default-approval-rule). To disable this feature:
One possible scenario would be to assign a group of approvers at the project
level and change them later when creating or editing the merge request.
First, you have to enable this option in the project's settings:
1. Navigate to your project's **Settings > General** and expand
**Merge request approvals**
1. Tick the "Can override approvers and approvals required per merge request"
checkbox
![Approvals can override](img/approvals_can_override.png)
1. Uncheck the **Can override approvers and approvals required per merge request** checkbox.
1. Click **Save changes** 1. Click **Save changes**
NOTE: **Note:** ### Resetting approvals on push
If approver overriding is enabled
and the project level approvers are changed after a merge request is created,
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).
The default approval settings can now be overridden when creating a You can force all approvals on a merge request to be removed when new commits are
[merge request](index.md) or by editing it after it's been created: 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. 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:**
If you are contributing to a forked project, things are a little different.
Read what happens when the
[source and target branches are not the same](#merge-requests-with-different-source-branch-and-target-branch-projects).
## Overriding merge request approvals default settings **(PREMIUM)**
In GitLab Premium, when the approval rules are [set at the project level](#editing-approvals-premium),
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
If approvals are [set at the project level](#editing-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
**Merge request approvals**
1. Tick the "Remove all approvals in a merge request when new commits are pushed to its source branch"
checkbox
![Approvals remove on push](img/approvals_remove_on_push.png)
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, ### Allowing merge request authors to approve their own merge requests
turn this setting to off by unchecking the box and saving the changes.
## 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).
## License compliance approvals in merge requests **(ULTIMATE)** ## Enabling the new approvals interface
> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.3. 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.
Merge Request Approvals can be configured to require approval from a member Use these commands to start the Rails console:
of your security team when a blacklisted software license would be introduced by a merge request.
For more information, see ```shell
[Security approvals in merge requests](../../application_security/index.md#security-approvals-in-merge-requests-ultimate). # 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 updated interface.
<!-- ## Troubleshooting <!-- ## Troubleshooting

View file

Before

Width:  |  Height:  |  Size: 30 KiB

After

Width:  |  Height:  |  Size: 30 KiB

View file

@ -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.

View file

@ -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
def api_post_body def api_post_body
{ {
description: @description, title: title
title: @title
} }
end end
end end

View file

@ -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|