Add latest changes from gitlab-org/gitlab@13-5-stable-eev13.5.0-rc42

11 files changed, 146 insertions, 58 deletions

diff --git a/doc/user/project/merge_requests/accessibility_testing.md b/doc/user/project/merge_requests/accessibility_testing.md
index f3a0aac9ff4..a07a155745e 100644
--- a/doc/user/project/merge_requests/accessibility_testing.md
+++ b/doc/user/project/merge_requests/accessibility_testing.md
@@ -55,7 +55,7 @@ include:
 ```
 
 creates an `a11y` job in your CI/CD pipeline, runs
-Pa11y against the webpages defined in `a11y_urls`, and builds an HTML report for each.
+Pa11y against the web pages defined in `a11y_urls`, and builds an HTML report for each.
 
 The report for each URL is saved as an artifact that can be [viewed directly in your browser](../../../ci/pipelines/job_artifacts.md#browsing-artifacts).
 
diff --git a/doc/user/project/merge_requests/allow_collaboration.md b/doc/user/project/merge_requests/allow_collaboration.md
index 60d247ccc19..4ba0b50a3cf 100644
--- a/doc/user/project/merge_requests/allow_collaboration.md
+++ b/doc/user/project/merge_requests/allow_collaboration.md
@@ -28,11 +28,12 @@ source project and only lasts while the merge request is open. Once enabled,
 upstream members will also be able to retry the pipelines and jobs of the
 merge request:
 
-1. Enable the contribution while creating or editing a merge request.
+1. While creating or editing a merge request, select the checkbox **Allow
+   commits from members who can merge to the target branch**.
 
    ![Enable contribution](img/allow_collaboration.png)
 
-1. Once the merge request is created, you'll see that commits from members who
+1. Once the merge request is created, you can see that commits from members who
    can merge to the target branch are allowed.
 
    ![Check that contribution is enabled](img/allow_collaboration_after_save.png)
diff --git a/doc/user/project/merge_requests/getting_started.md b/doc/user/project/merge_requests/getting_started.md
index a0be32e0708..462b8f68ece 100644
--- a/doc/user/project/merge_requests/getting_started.md
+++ b/doc/user/project/merge_requests/getting_started.md
@@ -111,6 +111,48 @@ It is also possible to manage multiple assignees:
 - When creating a merge request.
 - Using [quick actions](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics).
 
+## Reviewer
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216054) in GitLab 13.5.
+> - It's [deployed behind a feature flag](../../../user/feature_flags.md), enabled by default.
+> - It's disabled on GitLab.com.
+> - It's not recommended for production use.
+> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-merge-request-reviewers). **(CORE ONLY)**
+
+CAUTION: **Warning:**
+This feature might not be available to you. Check the **version history** note above for details.
+
+Requesting a code review is an important part of contributing code. However, deciding who should review
+your code and asking for a review are no easy tasks. Using the "assignee" field for both authors and
+reviewers makes it hard for others to determine who's doing what on a merge request.
+
+GitLab's Merge Request Reviewers easily allow authors to request a review as well as see the status of the
+review. By selecting one or more users from the **Reviewers** field in the merge request's right-hand
+sidebar, the assigned reviewers will receive a notification of the request to review the merge request.
+
+This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review from a peer.
+
+To request it, open the **Reviewers** drop-down box to search for the user you wish to get a review from.
+
+### Enable or disable Merge Request Reviewers **(CORE ONLY)**
+
+Merge Request Reviewers is under development and not ready for production use. It is
+deployed behind a feature flag that is **disabled by default**.
+[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
+can enable it.
+
+To enable it:
+
+```ruby
+Feature.enable(:merge_request_reviewers)
+```
+
+To disable it:
+
+```ruby
+Feature.disable(:merge_request_reviewers)
+```
+
 ### Merge requests to close issues
 
 If the merge request is being created to resolve an issue, you can
diff --git a/doc/user/project/merge_requests/img/commit_nav_v13_4.png b/doc/user/project/merge_requests/img/commit_nav_v13_4.png
new file mode 100644
index 00000000000..0ae6ce32693
--- /dev/null
+++ b/doc/user/project/merge_requests/img/commit_nav_v13_4.png
diff --git a/doc/user/project/merge_requests/load_performance_testing.md b/doc/user/project/merge_requests/load_performance_testing.md
index daebd71e14f..2675f509eed 100644
--- a/doc/user/project/merge_requests/load_performance_testing.md
+++ b/doc/user/project/merge_requests/load_performance_testing.md
@@ -164,8 +164,8 @@ For example:
    1. Capture the dynamic URL and save it into a `.env` file, e.g. `echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env`.
    1. Set the `.env` file to be a [job artifact](../../../ci/pipelines/job_artifacts.md#job-artifacts).
 1. In the `load_performance` job:
-   1. Set it to depend on the review job, so it inherits the env file.
-   1. Set the `K6_DOCKER_OPTIONS` variable with the [Docker cli option for env files](https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file), for example `--env-file review.env`.
+   1. Set it to depend on the review job, so it inherits the environment file.
+   1. Set the `K6_DOCKER_OPTIONS` variable with the [Docker CLI option for environment files](https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file), for example `--env-file review.env`.
 1. Configure the k6 test script to use the environment variable in it's steps.
 
 Your `.gitlab-ci.yml` file might be similar to:
diff --git a/doc/user/project/merge_requests/merge_request_approvals.md b/doc/user/project/merge_requests/merge_request_approvals.md
index 185ab0e6298..4b4c930c7af 100644
--- a/doc/user/project/merge_requests/merge_request_approvals.md
+++ b/doc/user/project/merge_requests/merge_request_approvals.md
@@ -5,13 +5,16 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference, concepts
 ---
 
-# Merge Request Approvals
+# Merge Request Approvals **(CORE)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/580) in GitLab Enterprise Edition 7.2. Available in GitLab Core and higher tiers.
+> - Redesign [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8 and [feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/10685) in 12.0.
 
 Code review is an essential practice of every successful project, and giving your
 approval once a merge request is in good shape is an important part of the review
 process, as it clearly communicates the ability to merge the change.
 
-## Optional Approvals **(CORE ONLY)**
+## Optional Approvals
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27426) in GitLab 13.2.
 
@@ -335,26 +338,6 @@ of your security team when a vulnerability would be introduced by a merge reques
 For more information, see
 [Security approvals in merge requests](../../application_security/index.md#security-approvals-in-merge-requests).
 
-### Enabling the new approvals interface
-
-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.
-
-Use these commands to start the Rails console:
-
-```shell
-# Omnibus GitLab
-gitlab-rails console
-
-# Installation from source
-cd /home/git/gitlab
-sudo -u git -H bin/rails console -e production
-```
-
-Then run `Feature.enable(:approval_rules)` to enable the updated interface.
-
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/project/merge_requests/revert_changes.md b/doc/user/project/merge_requests/revert_changes.md
index bc4fee749e8..6b302b0ff02 100644
--- a/doc/user/project/merge_requests/revert_changes.md
+++ b/doc/user/project/merge_requests/revert_changes.md
@@ -14,7 +14,7 @@ by clicking the **Revert** button in merge requests and commit details.
 
 NOTE: **Note:**
 The **Revert** button will only be available for merge requests
-created since GitLab 8.5. However, you can still revert a merge request
+created in GitLab 8.5 and later. However, you can still revert a merge request
 by reverting the merge commit from the list of Commits page.
 
 NOTE: **Note:**
diff --git a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
index 3a18cacde64..aef68e0e771 100644
--- a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
+++ b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
@@ -84,7 +84,7 @@ Click **Expand file** on any file to view the changes for that file.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-file-by-file-diff-navigation).
 
 For larger merge requests it might sometimes be useful to review single files at a time. To enable,
-from your avatar on the top-right navbar, click **Settings**, and go to **Preferences** on the left
+from your avatar on the top-right navigation bar, click **Settings**, and go to **Preferences** on the left
 sidebar. Scroll down to the **Behavior** section and select **Show one file at a time on merge request's Changes tab**.
 Click **Save changes** to apply.
 
@@ -122,6 +122,8 @@ the commits to open the single-commit view. From there, you can navigate among t
 by clicking the **Prev** and **Next** buttons on the top-right of the page or by using the
 <kbd>X</kbd> and <kbd>C</kbd> keyboard shortcuts.
 
+![Merge requests commit navigation](img/commit_nav_v13_4.png)
+
 ### Incrementally expand merge request diffs
 
 By default, the diff shows only the parts of a file which are changed.
diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md
index 69a0dd6e84f..68f5478038a 100644
--- a/doc/user/project/merge_requests/squash_and_merge.md
+++ b/doc/user/project/merge_requests/squash_and_merge.md
@@ -65,8 +65,8 @@ meaningful commit messages and:
 ## Enabling squash for a merge request
 
 Anyone who can create or edit a merge request can choose for it to be squashed
-on the merge request form. Users can select or unselect the checkbox at the moment
-they are creating the merge request:
+on the merge request form. Users can select or clear the check box when they
+create the merge request:
 
 ![Squash commits checkbox on edit form](img/squash_edit_form.png)
 
diff --git a/doc/user/project/merge_requests/test_coverage_visualization.md b/doc/user/project/merge_requests/test_coverage_visualization.md
index 56b5774f15b..bded1839f97 100644
--- a/doc/user/project/merge_requests/test_coverage_visualization.md
+++ b/doc/user/project/merge_requests/test_coverage_visualization.md
@@ -5,13 +5,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference, howto
 ---
 
-# Test Coverage Visualization **(CORE ONLY)**
+# Test Coverage Visualization
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3708) in GitLab 12.9.
-> - [Feature flag enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/211410) in GitLab 13.4.
-> - It's enabled on GitLab.com.
-> - It can be disabled per-project.
-> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enabling-the-feature). **(CORE ONLY)**
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/249811) in GitLab 13.5.
 
 With the help of [GitLab CI/CD](../../../ci/README.md), you can collect the test
 coverage information of your favorite testing or coverage-analysis tool, and visualize
@@ -58,7 +55,9 @@ NOTE: **Note:**
 The Cobertura XML parser currently does not support the `sources` element and ignores it. It is assumed that
 the `filename` of a `class` element contains the full path relative to the project root.
 
-## Example test coverage configuration
+## Example test coverage configurations
+
+### JavaScript example
 
 The following [`gitlab-ci.yml`](../../../ci/yaml/README.md) example uses [Mocha](https://mochajs.org/)
 JavaScript testing and [NYC](https://github.com/istanbuljs/nyc) coverage-tooling to
@@ -74,26 +73,84 @@ test:
       cobertura: coverage/cobertura-coverage.xml
 ```
 
-## Enabling the feature
+### Java examples
+
+#### Maven example
 
-This feature comes with the `:coverage_report_view` feature flag enabled by
-default. It is enabled on GitLab.com. [GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
-can disable it for your instance. Test coverage visualization can be enabled or disabled per-project.
+The following [`gitlab-ci.yml`](../../../ci/yaml/README.md) example for Java uses [Maven](https://maven.apache.org/)
+to build the project and [Jacoco](https://www.eclemma.org/jacoco/) coverage-tooling to
+generate the coverage artifact.
+You can check the [Docker image configuration and scripts](https://gitlab.com/haynes/jacoco2cobertura) if you want to build your own image.
 
-To enable it:
+GitLab expects the artifact in the Cobertura format, so you have to execute a few
+scripts before uploading it. The `test-jdk11` job tests the code and generates an
+XML artifact. The `coverage-jdk-11` job converts the artifact into a Cobertura report:
 
-```ruby
-# Instance-wide
-Feature.enable(:coverage_report_view)
-# or by project
-Feature.enable(:coverage_report_view, Project.find(<project id>))
+```yaml
+test-jdk11:
+  stage: test
+  image: maven:3.6.3-jdk-11
+  script:
+    - 'mvn $MAVEN_CLI_OPTS clean org.jacoco:jacoco-maven-plugin:prepare-agent test jacoco:report'
+  artifacts:
+    paths:
+      - target/site/jacoco/jacoco.xml
+
+coverage-jdk11:
+  # Must be in a stage later than test-jdk11's stage.
+  # The `visualize` stage does not exist by default.
+  # Please define it first, or chose an existing stage like `deploy`.
+  stage: visualize
+  image: haynes/jacoco2cobertura:1.0.3
+  script:
+    # convert report from jacoco to cobertura
+    - 'python /opt/cover2cover.py target/site/jacoco/jacoco.xml src/main/java > target/site/cobertura.xml'
+    # read the <source></source> tag and prepend the path to every filename attribute
+    - 'python /opt/source2filename.py target/site/cobertura.xml'
+  needs: ["test-jdk11"]
+  dependencies:
+    - test-jdk11
+  artifacts:
+    reports:
+      cobertura: target/site/cobertura.xml
 ```
 
-To disable it:
+#### Gradle example
 
-```ruby
-# Instance-wide
-Feature.disable(:coverage_report_view)
-# or by project
-Feature.disable(:coverage_report_view, Project.find(<project id>))
+The following [`gitlab-ci.yml`](../../../ci/yaml/README.md) example for Java uses [Gradle](https://gradle.org/)
+to build the project and [Jacoco](https://www.eclemma.org/jacoco/) coverage-tooling to
+generate the coverage artifact.
+You can check the [Docker image configuration and scripts](https://gitlab.com/haynes/jacoco2cobertura) if you want to build your own image.
+
+GitLab expects the artifact in the Cobertura format, so you have to execute a few
+scripts before uploading it. The `test-jdk11` job tests the code and generates an
+XML artifact. The `coverage-jdk-11` job converts the artifact into a Cobertura report:
+
+```yaml
+test-jdk11:
+  stage: test
+  image: gradle:6.6.1-jdk11
+  script:
+    - 'gradle test jacocoTestReport' # jacoco must be configured to create an xml report
+  artifacts:
+    paths:
+      - build/jacoco/jacoco.xml
+
+coverage-jdk11:
+  # Must be in a stage later than test-jdk11's stage.
+  # The `visualize` stage does not exist by default.
+  # Please define it first, or chose an existing stage like `deploy`.
+  stage: visualize
+  image: haynes/jacoco2cobertura:1.0.3
+  script:
+    # convert report from jacoco to cobertura
+    - 'python /opt/cover2cover.py build/jacoco/jacoco.xml src/main/java > build/cobertura.xml'
+    # read the <source></source> tag and prepend the path to every filename attribute
+    - 'python /opt/source2filename.py build/cobertura.xml'
+  needs: ["test-jdk11"]
+  dependencies:
+    - test-jdk11
+  artifacts:
+    reports:
+      cobertura: build/cobertura.xml
 ```
diff --git a/doc/user/project/merge_requests/work_in_progress_merge_requests.md b/doc/user/project/merge_requests/work_in_progress_merge_requests.md
index d1833318a85..e7abf6e5fb6 100644
--- a/doc/user/project/merge_requests/work_in_progress_merge_requests.md
+++ b/doc/user/project/merge_requests/work_in_progress_merge_requests.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference, concepts
 ---
 
-# Draft merge requests
+# Draft merge requests **(CORE)**
 
 If a merge request is not yet ready to be merged, perhaps due to continued development
 or open threads, you can prevent it from being accepted before it's ready by flagging
@@ -16,10 +16,12 @@ being merged, and it will stay disabled until the "Draft" flag has been removed.
 
 ## Adding the "Draft" flag to a merge request
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32692) in GitLab 13.2, Work-In-Progress (WIP) merge requests were renamed to **Draft**. Support for using **WIP** will be removed in GitLab 14.0.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32692) in GitLab 13.2, Work-In-Progress (WIP) merge requests were renamed to **Draft**. Support for using **WIP** will be removed in GitLab 14.0.
+> - **Mark as draft** and **Mark as ready** buttons [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/227421) in GitLab 13.5.
 
 There are several ways to flag a merge request as a Draft:
 
+- Click the **Mark as draft** button on the top-right corner of the merge request's page.
 - Add `[Draft]`, `Draft:` or `(Draft)` to the start of the merge request's title. Clicking on
   **Start the title with Draft:**, under the title box, when editing the merge request's
   description will have the same effect.
@@ -28,15 +30,16 @@ There are several ways to flag a merge request as a Draft:
 - Add the `/wip` [quick action](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics)
   in a comment in the merge request. This is a toggle, and can be repeated
   to change the status back. Note that any other text in the comment will be discarded.
-- Add `draft:` or `Draft:` to the start of a commit message targeting the merge request's
-  source branch. This is not a toggle, and doing it again in another commit will have
-  no effect.
+- Add `draft:`, `Draft:`, `fixup!`, or `Fixup!` to the beginning of a commit message targeting the
+  merge request's source branch. This is not a toggle, and doing it again in another
+  commit will have no effect.
 
 ## Removing the "Draft" flag from a merge request
 
 Similar to above, when a Merge Request is ready to be merged, you can remove the
 `Draft` flag in several ways:
 
+- Click the **Mark as ready** button on the top-right corner of the merge request's page.
 - Remove `[Draft]`, `Draft:` or `(Draft)` from the start of the merge request's title. Clicking on
   **Remove the Draft: prefix from the title**, under the title box, when editing the merge
   request's description, will have the same effect.