Skip to content

G
gitlab-ce
Commit 12e19697 authored by Marcel Amirault's avatar Marcel Amirault Committed by Achilleas Pipinellis
Browse files
Options

Docs: Merge EE doc/user/project/merge_requests to CE

parent 205df512
Show whitespace changes
Inline Side-by-side
Showing with 576 additions and 9 deletions
doc/user/project/merge_requests/browser_performance_testing.md 0 → 100644
View file @ 12e19697
# Browser Performance Testing **[PREMIUM]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3507)
in [GitLab Premium](https://about.gitlab.com/pricing/) 10.3.
## Overview
If your application offers a web interface and you are using
[GitLab CI/CD](../../../ci/README.md), you can quickly determine the performance
impact of pending code changes.
GitLab uses [Sitespeed.io](https://www.sitespeed.io), a free and open source
tool for measuring the performance of web sites, and has built a simple
[Sitespeed plugin](https://gitlab.com/gitlab-org/gl-performance)
which outputs the results in a file called `performance.json`. This plugin
outputs the performance score for each page that is analyzed.
The [Sitespeed.io performance score](http://examples.sitespeed.io/6.0/2017-11-23-23-43-35/help.html)
is a composite value based on best practices, and we will be expanding support
for [additional metrics](https://gitlab.com/gitlab-org/gitlab-ee/issues/4370)
in a future release.
Going a step further, GitLab can show the Performance report right
in the merge request widget area:
## Use cases
For instance, consider the following workflow:
1. A member of the marketing team is attempting to track engagement by adding a new tool
1. With browser performance metrics, they see how their changes are impacting the usability of the page for end users
1. The metrics show that after their changes the performance score of the page has gone down
1. When looking at the detailed report, they see that the new Javascript library was included in `<head>` which affects loading page speed
1. They ask a front end developer to help them, who sets the library to load asynchronously
1. The frontend developer approves the merge request and authorizes its deployment to production
## How it works
First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
[Performance report artifact](../../../ci/yaml/README.md#artifactsreportsperformance-premium).
For more information on how the Performance job should look like, check the
example on [Testing Browser Performance](../../../ci/examples/browser_performance.md).
GitLab then checks this report, compares key performance metrics for each page
between the source and target branches, and shows the information right on the merge request.
>**Note:**
If the Performance report doesn't have anything to compare to, no information
will be displayed in the merge request area. That is the case when you add the
Performance job in your `.gitlab-ci.yml` for the very first time.
Consecutive merge requests will have something to compare to and the Performance
report will be shown properly.
![Performance Widget](img/browser_performance_testing.png)
doc/user/project/merge_requests/code_quality.md 0 → 100644
View file @ 12e19697
# Code Quality **[STARTER]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1984)
in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
## Overview
If you are using [GitLab CI/CD](../../../ci/README.md), you can analyze your
source code quality using GitLab Code Quality.
Code Quality uses [Code Climate Engines](https://codeclimate.com), which are
free and open source. Code Quality doesn’t require a Code Climate subscription.
Going a step further, GitLab can show the Code Quality report right
in the merge request widget area:
![Code Quality Widget](img/code_quality.gif)
## Use cases
For instance, consider the following workflow:
1. Your backend team member starts a new implementation for making certain feature in your app faster
1. With Code Quality reports, they analyze how their implementation is impacting the code quality
1. The metrics show that their code degrade the quality in 10 points
1. You ask a co-worker to help them with this modification
1. They both work on the changes until Code Quality report displays no degradations, only improvements
1. You approve the merge request and authorize its deployment to staging
1. Once verified, their changes are deployed to production
## How it works
First of all, you need to define a job in your `.gitlab-ci.yml` file that generates the
[Code Quality report artifact](../../../ci/yaml/README.md#artifactsreportscodequality-starter).
The Code Quality report artifact is a subset of the
[Code Climate spec](https://github.com/codeclimate/spec/blob/master/SPEC.md#data-types).
It must be a JSON file containing an array of objects with the following properties:
| Name | Description |
| ---------------------- | -------------------------------------------------------------------------------------- |
| `description` | A description of the code quality violation. |
| `fingerprint` | A unique fingerprint to identify the code quality violation. For example, an MD5 hash. |
| `location.path` | The relative path to the file containing the code quality violation. |
| `location.lines.begin` | The line on which the code quality violation occurred. |
Example:
```json
[
{
"description": "'unused' is assigned a value but never used.",
"fingerprint": "7815696ecbf1c96e6894b779456d330e",
"location": {
"path": "lib/index.js",
"lines": {
"begin": 42
}
}
}
]
```
NOTE: **Note:**
Although the Code Climate spec supports more properties, those are ignored by GitLab.
For more information on how the Code Quality job should look like, check the
example on [analyzing a project's code quality](../../../ci/examples/code_quality.md).
GitLab then checks this report, compares the metrics between the source and target
branches, and shows the information right on the merge request.
CAUTION: **Caution:**
If multiple jobs in a pipeline generate a code quality artifact, only the artifact from
the last created job (the job with the largest job ID) is used. To avoid confusion,
configure only one job to generate a code quality artifact.
NOTE: **Note:**
If the Code Quality report doesn't have anything to compare to, no information
will be displayed in the merge request area. That is the case when you add the
Code Quality job in your `.gitlab-ci.yml` for the very first time.
Consecutive merge requests will have something to compare to and the Code Quality
report will be shown properly.
doc/user/project/merge_requests/code_quality_diff.md 0 → 100644
View file @ 12e19697
---
redirect_from: 'https://docs.gitlab.com/ee/user/project/merge_requests/code_quality_diff.html'
redirect_to: 'code_quality.md'
---
This document was moved to [another location](code_quality.md).
doc/user/project/merge_requests/container_scanning.md 0 → 100644
View file @ 12e19697
---
redirect_to: 'https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html'
---
This document was moved to [another location](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html).
doc/user/project/merge_requests/dast.md 0 → 100644
View file @ 12e19697
---
redirect_to: 'https://docs.gitlab.com/ee/user/application_security/dast/index.html'
---
This document was moved to [another location](https://docs.gitlab.com/ee/user/application_security/dast/index.html).
doc/user/project/merge_requests/dependency_scanning.md 0 → 100644
View file @ 12e19697
---
redirect_to: 'https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html'
---
This document was moved to [another location](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html).
doc/user/project/merge_requests/index.md
View file @ 12e19697
...@@ -23,7 +23,7 @@ With GitLab merge requests, you can: ...@@ -23,7 +23,7 @@ With GitLab merge requests, you can:
- Assign it to any registered user, and change the assignee how many times you need - Assign it to any registered user, and change the assignee how many times you need
- Assign a [milestone](../../project/milestones/index.md) and track the development of a broader implementation - Assign a [milestone](../../project/milestones/index.md) and track the development of a broader implementation
- Organize your issues and merge requests consistently throughout the project with [labels](../../project/labels.md) - Organize your issues and merge requests consistently throughout the project with [labels](../../project/labels.md)
- Add a time estimation and the time spent with that merge request with [Time Tracking](../../../workflow/time_tracking.html#time-tracking) - Add a time estimation and the time spent with that merge request with [Time Tracking](../../../workflow/time_tracking.md#time-tracking)
- [Resolve merge conflicts from the UI](#resolve-conflicts) - [Resolve merge conflicts from the UI](#resolve-conflicts)
- Enable [fast-forward merge requests](#fast-forward-merge-requests) - Enable [fast-forward merge requests](#fast-forward-merge-requests)
- Enable [semi-linear history merge requests](#semi-linear-history-merge-requests) as another security layer to guarantee the pipeline is passing in the target branch - Enable [semi-linear history merge requests](#semi-linear-history-merge-requests) as another security layer to guarantee the pipeline is passing in the target branch
...@@ -33,9 +33,16 @@ With GitLab merge requests, you can: ...@@ -33,9 +33,16 @@ With GitLab merge requests, you can:
With **[GitLab Enterprise Edition][ee]**, you can also: With **[GitLab Enterprise Edition][ee]**, you can also:
- View the deployment process across projects with [Multi-Project Pipeline Graphs](https://docs.gitlab.com/ee/ci/multi_project_pipeline_graphs.html#multi-project-pipeline-graphs) **[PREMIUM]** - Prepare a full review and submit it once it's ready with [Merge Request Reviews](https://docs.gitlab.com/ee/user/discussions/index.md#merge-request-reviews-premium) **[PREMIUM]**
- Request [approvals](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html) from your managers **[STARTER]** - View the deployment process across projects with [Multi-Project Pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipelines.md) **[PREMIUM]**
- Analyze the impact of your changes with [Code Quality reports](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html) **[STARTER]** - Request [approvals](merge_request_approvals.md) from your managers **[STARTER]**
- Analyze the impact of your changes with [Code Quality reports](code_quality.md) **[STARTER]**
- Manage the licenses of your dependencies with [License Management](https://docs.gitlab.com/ee/user/application_security/license_management/index.md) **[ULTIMATE]**
- Analyze your source code for vulnerabilities with [Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/index.md) **[ULTIMATE]**
- Analyze your running web applications for vulnerabilities with [Dynamic Application Security Testing](https://docs.gitlab.com/ee/user/application_security/dast/index.md) **[ULTIMATE]**
- Analyze your dependencies for vulnerabilities with [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.md) **[ULTIMATE]**
- Analyze your Docker images for vulnerabilities with [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.md) **[ULTIMATE]**
- Determine the performance impact of changes with [Browser Performance Testing](#browser-performance-testing-premium) **[PREMIUM]**
## Use cases ## Use cases
...@@ -43,19 +50,21 @@ A. Consider you are a software developer working in a team: ...@@ -43,19 +50,21 @@ A. Consider you are a software developer working in a team:
1. You checkout a new branch, and submit your changes through a merge request 1. You checkout a new branch, and submit your changes through a merge request
1. You gather feedback from your team 1. You gather feedback from your team
1. You work on the implementation optimizing code with [Code Quality reports](code_quality.md) **[STARTER]**
1. You verify your changes with [JUnit test reports](../../../ci/junit_test_reports.md) in GitLab CI/CD 1. You verify your changes with [JUnit test reports](../../../ci/junit_test_reports.md) in GitLab CI/CD
1. You request the approval from your manager 1. You avoid using dependencies whose license is not compatible with your project with [License Management reports](license_management.md) **[ULTIMATE]**
1. Your manager pushes a commit with his final review, [approves the merge request](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html), and set it to [merge when pipeline succeeds](#merge-when-pipeline-succeeds) (Merge Request Approvals are available in GitLab Starter) 1. You request the [approval](#merge-request-approvals-starter) from your manager
1. Your manager pushes a commit with their final review, [approves the merge request](merge_request_approvals.md), and set it to [merge when pipeline succeeds](#merge-when-pipeline-succeeds) (Merge Request Approvals are available in GitLab Starter)
1. Your changes get deployed to production with [manual actions](../../../ci/yaml/README.md#whenmanual) for GitLab CI/CD 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 1. Your implementations were successfully shipped to your customer
B. Consider you're a web developer writing a webpage for your company's: B. Consider you're a web developer writing a webpage for your company's website:
1. You checkout a new branch, and submit a new page through a merge request 1. You checkout a new branch, and submit a new page through a merge request
1. You gather feedback from your reviewers 1. You gather feedback from your reviewers
1. Your changes are previewed with [Review Apps](../../../ci/review_apps/index.md) 1. Your changes are previewed with [Review Apps](../../../ci/review_apps/index.md)
1. You request your web designers for their implementation 1. You request your web designers for their implementation
1. You request the [approval](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html) from your manager **[STARTER]** 1. You request the [approval](merge_request_approvals.md) from your manager **[STARTER]**
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/2016/08/26/ci-deployment-and-environments/) 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/2016/08/26/ci-deployment-and-environments/)
1. Your production team [cherry picks](#cherry-pick-changes) the merge commit into production 1. Your production team [cherry picks](#cherry-pick-changes) the merge commit into production
...@@ -159,6 +168,21 @@ in a Merge Request. To do so, click the **...** button in the gutter of the Merg ...@@ -159,6 +168,21 @@ in a Merge Request. To do so, click the **...** button in the gutter of the Merg
![Comment on any diff file line](img/comment-on-any-diff-line.png) ![Comment on any diff file line](img/comment-on-any-diff-line.png)
## Perform a Review **[PREMIUM]**
Start a review in order to create multiple comments on a diff and publish them once you're ready.
Starting a review allows you to get all your thoughts in order and ensure you haven't missed anything
before submitting all your comments.
[Learn more about Merge Request Reviews](https://docs.gitlab.com/ee/user/discussions/index.html#merge-request-reviews-premium)
## Squash and merge
GitLab allows you to squash all changes present in a merge request into a single
commit when merging, to allow for a neater commit history.
[Learn more about squash and merge.](squash_and_merge.md)
## Suggest changes ## Suggest changes
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/18008) in GitLab 11.6. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/18008) in GitLab 11.6.
...@@ -182,7 +206,7 @@ To assign multiple assignees to a merge request: ...@@ -182,7 +206,7 @@ To assign multiple assignees to a merge request:
1. From a merge request, expand the right sidebar and locate the **Assignees** section. 1. From a merge request, expand the right sidebar and locate the **Assignees** section.
1. Click on **Edit** and from the dropdown menu, select as many users as you want 1. Click on **Edit** and from the dropdown menu, select as many users as you want
to assign the merge request to. to assign the merge request to.
Similarly, assignees are removed by deselecting them from the same dropdown menu. Similarly, assignees are removed by deselecting them from the same dropdown menu.
...@@ -336,6 +360,52 @@ have been marked as a **Work In Progress**. ...@@ -336,6 +360,52 @@ have been marked as a **Work In Progress**.
[Learn more about setting a merge request as "Work In Progress".](work_in_progress_merge_requests.md) [Learn more about setting a merge request as "Work In Progress".](work_in_progress_merge_requests.md)
## Merge request approvals **[STARTER]**
> Included in [GitLab Starter][products].
If you want to make sure every merge request is approved by one or more people,
you can enforce this workflow by using merge request approvals. Merge request
approvals allow you to set the number of necessary approvals and predefine a
list of approvers that will need to approve every merge request in a project.
[Read more about merge request approvals.](merge_request_approvals.md)
## Code Quality **[STARTER]**
> Introduced in [GitLab Starter][products] 9.3.
If you are using [GitLab CI][ci], you can analyze your source code quality using
the [Code Climate][cc] analyzer [Docker image][cd]. Going a step further, GitLab
can show the Code Climate report right in the merge request widget area.
[Read more about Code Quality reports.](code_quality.md)
## Browser Performance Testing **[PREMIUM]**
> Introduced in [GitLab Premium][products] 10.3.
If your application offers a web interface and you are using [GitLab CI/CD][ci], you can quickly determine the performance impact of pending code changes. GitLab uses [Sitespeed.io][sitespeed], a free and open source tool for measuring the performance of web sites, to analyze the performance of specific pages.
GitLab runs the [Sitespeed.io container][sitespeed-container] and displays the difference in overall performance scores between the source and target branches.
[Read more about Browser Performance Testing.](browser_performance_testing.md)
## Security reports **[ULTIMATE]**
GitLab can scan and report any vulnerabilities found in your project.
[Read more about security reports.](https://docs.gitlab.com/ee/user/application_security/index.html)
## Live preview with Review Apps
If you configured [Review Apps](https://about.gitlab.com/features/review-apps/) for your project,
you can preview the changes submitted to a feature-branch through a merge request
in a per-branch basis. No need to checkout the branch, install and preview locally;
all your changes will be available to preview by anyone with the Review Apps link.
[Read more about Review Apps.](../../../ci/review_apps/index.md)
## Merge request diff file navigation ## Merge request diff file navigation
When reviewing changes in the **Changes** tab the diff can be navigated using When reviewing changes in the **Changes** tab the diff can be navigated using
...@@ -528,5 +598,11 @@ And to check out a particular merge request: ...@@ -528,5 +598,11 @@ And to check out a particular merge request:
git checkout origin/merge-requests/1 git checkout origin/merge-requests/1
``` ```
[products]: https://about.gitlab.com/products/ "GitLab products page"
[protected branches]: ../protected_branches.md [protected branches]: ../protected_branches.md
[ci]: ../../../ci/README.md
[cc]: https://codeclimate.com/
[cd]: https://hub.docker.com/r/codeclimate/codeclimate/
[sitespeed]: https://www.sitespeed.io
[sitespeed-container]: https://hub.docker.com/r/sitespeedio/sitespeed.io/
[ee]: https://about.gitlab.com/pricing/ "GitLab Enterprise Edition" [ee]: https://about.gitlab.com/pricing/ "GitLab Enterprise Edition"
doc/user/project/merge_requests/license_management.md 0 → 100644
View file @ 12e19697
---
redirect_to: 'https://docs.gitlab.com/ee/user/application_security/license_management/index.html'
---
This document was moved to [another location](https://docs.gitlab.com/ee/user/application_security/license_management/index.html).
doc/user/project/merge_requests/merge_request_approvals.md 0 → 100644
View file @ 12e19697
# Merge request approvals **[STARTER]**
> Introduced in [GitLab Enterprise Edition 7.12](https://about.gitlab.com/2015/06/22/gitlab-7-12-released/#merge-request-approvers-ee-only).
NOTE: **Note:**
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.
The documentation for the older interface can be accessed
[here](/11.7/ee/user/project/merge_requests/merge_request_approvals.html).
## Overview
Merge request approvals enable enforced code review by requiring specified people to approve a merge request before it can be unblocked for merging.
## Use cases
1. Enforcing review of all code that gets merged into a repository.
2. Specifying code maintainers for an entire repository.
3. Specifying reviewers for a given proposed code change.
4. Specifying categories of reviewers, such as BE, FE, QA, DB, etc., for all proposed code changes.
## 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-ee/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8.
CAUTION: **Caution:**
There was a [regression affecting this feature in 11.8](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9648). We recommend upgrading _at least_ to version 11.8.2. to avoid any issues.
NOTE: **Note:**
In 11.8 this feature does not work in [private groups](https://gitlab.com/gitlab-org/gitlab-ee/issues/10356).
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 aprovals required.
1. Give the approval rule a name that describes the set of approvers selected.
1. Click **Add approvers** to submit the new rule.
![Approvals premium project edit](img/approvals_premium_project_edit.png)
## Multiple approval rules **[PREMIUM]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8.
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:
- Users being added as approvers at project or merge request level.
- [Code owners](https://docs.gitlab.com/ee/user/project/code_owners.html) related to the merge request ([introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/7933) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.5).
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 can also be added as an approver. [In the future](https://gitlab.com/gitlab-org/gitlab-ee/issues/2048),
group approvers will be restricted.
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
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.
### Implicit approvers
If the number of required approvals is greater than the number of approvers,
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
If approvals are activated for the given project, when a user visits an open
merge request, depending on their [eligibility](#eligible-approvers), one of
the following is possible:
- **They are not an eligible approver**: They cannot do anything with respect
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.
![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)
NOTE: **Note:**
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-discussions-are-resolved)
or a [failed CI/CD pipeline](merge_when_pipeline_succeeds.md).
## Code Owners approvals **[PREMIUM]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/4418) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.9.
It is possible to require at least one approval for each entry in the
[`CODEOWNERS` file](https://docs.gitlab.com/ee/user/project/code_owners.html) that matches a file changed in
the merge request. To enable this feature:
1. Navigate to your project's **Settings > General** and expand
**Merge request approvals**.
1. Tick the **Require approval from code owners** checkbox
checkbox.
1. Click **Save changes**.
When this feature is enabled, all merge requests will need approval
from one code owner per matched rule before it can be merged.
## Overriding the merge request approvals default settings
> Introduced in GitLab Enterprise Edition 9.4.
NOTE: **Note:**
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
default configuration (number of required approvals and approvers) can be
overridden for each merge request in that project.
One possible scenario would be to 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. Click **Save changes**
NOTE: **Note:**
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
[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**.
There are however some restrictions:
- The amount of required approvals, if changed, must be greater than the default
set at the project level. This ensures that you're not forced to adjust settings
when someone is unavailable for approval, yet the process is still enforced.
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, there are a few more
restrictions (compared to [GitLab Starter](#overriding-the-merge-request-approvals-default-settings)):
- Approval rules can be added to an MR with no restriction.
- For project sourced approval rules, editing and removing approvers is not allowed.
- The approvals required of all approval rules is configurable, but if a rule is backed by a project rule, then it is restricted
to the minimum approvals required set in the project's corresponding rule.
## 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. Click **Save changes**
NOTE: **Note:**
Approvals do not get reset when [rebasing a merge request](fast_forward_merge.md)
from the UI.
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
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/3349) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.3.
You can allow merge request authors to self-approve merge requests by
enabling it [at the project level](#editing-approvals). Authors
also need to be included in the approvers list in order to be able to
approve their merge request.
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, which is enabled by default.
1. Click **Save changes**.
## Prevent approval of merge requests by their committers
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/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
enabling [**Prevent approval of merge requests by their committers**](#prevent-approval-of-merge-requests-by-their-committers).
1. Navigate to your project's **Settings > General** and expand **Merge request approvals**.
1. Tick the checkbox **Prevent approval of merge requests by their committers**.
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-ee/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)
doc/user/project/merge_requests/sast.md 0 → 100644
View file @ 12e19697
---
redirect_to: 'https://docs.gitlab.com/ee/user/application_security/sast/index.html'
---
This document was moved to [another location](https://docs.gitlab.com/ee/user/application_security/sast/index.html).
doc/user/project/merge_requests/sast_docker.md 0 → 100644
View file @ 12e19697
---
redirect_to: 'https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html'
---
This document was moved to [another location](https://docs.gitlab.com/ee/user/application_security/container_scanning/index.html).
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