Add latest changes from gitlab-org/gitlab@13-4-stable-ee

12 files changed, 144 insertions, 59 deletions

diff --git a/doc/user/project/merge_requests/browser_performance_testing.md b/doc/user/project/merge_requests/browser_performance_testing.md
index 10457e40e0b..040ca4b439b 100644
--- a/doc/user/project/merge_requests/browser_performance_testing.md
+++ b/doc/user/project/merge_requests/browser_performance_testing.md
@@ -37,7 +37,7 @@ Consider the following workflow:
 ## How browser performance testing works
 
 First, define a job in your `.gitlab-ci.yml` file that generates the
-[Browser Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium).
+[Browser Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance).
 GitLab then checks this report, compares key performance metrics for each page
 between the source and target branches, and shows the information in the merge request.
 
@@ -85,7 +85,7 @@ The example uses a CI/CD template that is included in all GitLab installations s
 or older, you must [add the configuration manually](#gitlab-versions-123-and-older)
 
 The template uses the [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance),
-and it saves the full HTML sitespeed.io report as a [Browser Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium)
+and it saves the full HTML sitespeed.io report as a [Browser Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance)
 that you can later download and analyze. This implementation always takes the latest
 Browser Performance artifact available. If [GitLab Pages](../pages/index.md) is enabled,
 you can view the report directly in your browser.
@@ -93,7 +93,7 @@ you can view the report directly in your browser.
 You can also customize the jobs with environment variables:
 
 - `SITESPEED_IMAGE`: Configure the Docker image to use for the job (default `sitespeedio/sitespeed.io`), but not the image version.
-- `SITESPEED_VERSION`: Configure the version of the Docker image to use for the job (default `13.3.0`).
+- `SITESPEED_VERSION`: Configure the version of the Docker image to use for the job (default `14.1.0`).
 - `SITESPEED_OPTIONS`: Configure any additional sitespeed.io options as required (default `nil`). Refer to the [sitespeed.io documentation](https://www.sitespeed.io/documentation/sitespeed.io/configuration/) for more details.
 
 For example, you can override the number of runs sitespeed.io
@@ -196,13 +196,13 @@ performance:
   image: docker:git
   variables:
     URL: https://example.com
-    SITESPEED_VERSION: 13.3.0
+    SITESPEED_VERSION: 14.1.0
     SITESPEED_OPTIONS: ''
   services:
     - docker:stable-dind
   script:
     - mkdir gitlab-exporter
-    - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
+    - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/1.1.0/index.js
     - mkdir sitespeed-results
     - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:$SITESPEED_VERSION --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL $SITESPEED_OPTIONS
     - mv sitespeed-results/data/performance.json performance.json
@@ -226,7 +226,7 @@ performance:
     - docker:stable-dind
   script:
     - mkdir gitlab-exporter
-    - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
+    - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/1.1.0/index.js
     - mkdir sitespeed-results
     - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL
     - mv sitespeed-results/data/performance.json performance.json
diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md
index 3c697e22cf5..e03d4e99b86 100644
--- a/doc/user/project/merge_requests/code_quality.md
+++ b/doc/user/project/merge_requests/code_quality.md
@@ -23,7 +23,7 @@ Code Quality:
   Quality](https://gitlab.com/gitlab-org/ci-cd/codequality) project using [default Code Climate configurations](https://gitlab.com/gitlab-org/ci-cd/codequality/-/tree/master/codeclimate_defaults).
 - Can make use of a [template](#example-configuration).
 - Is available with [Auto
-  DevOps](../../../topics/autodevops/stages.md#auto-code-quality-starter).
+  DevOps](../../../topics/autodevops/stages.md#auto-code-quality).
 - Can be extended through [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) or a [custom tool](#implementing-a-custom-tool).
 
 ## Code Quality Widget
@@ -69,7 +69,7 @@ For instance, consider the following workflow:
 
 This example shows how to run Code Quality on your code by using GitLab CI/CD and Docker.
 It requires GitLab 11.11 or later, and GitLab Runner 11.5 or later. If you are using
-GitLab 11.4 or ealier, you can view the deprecated job definitions in the
+GitLab 11.4 or earlier, you can view the deprecated job definitions in the
 [documentation archive](https://docs.gitlab.com/12.10/ee/user/project/merge_requests/code_quality.html#previous-job-definitions).
 
 First, you need GitLab Runner configured:
@@ -77,7 +77,7 @@ First, you need GitLab Runner configured:
 - For the [Docker-in-Docker workflow](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
 - With enough disk space to handle generated Code Quality files. For example on the [GitLab project](https://gitlab.com/gitlab-org/gitlab) the files are approximately 7 GB.
 
-Once you set up the Runner, include the Code Quality template in your CI configuration:
+Once you set up GitLab Runner, include the Code Quality template in your CI configuration:
 
 ```yaml
 include:
@@ -102,6 +102,16 @@ code_quality:
     CODE_QUALITY_IMAGE: "registry.example.com/codequality-fork:latest"
 ```
 
+In [GitLab 13.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/11100), you can override the [Code Quality environment variables](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables):
+
+```yaml
+variables:
+  TIMEOUT_SECONDS: 1
+
+include:
+  - template: Code-Quality.gitlab-ci.yml
+```
+
 By default, report artifacts are not downloadable. If you need them downloadable on the
 job details page, you can add `gl-code-quality-report.json` to the artifact paths like so:
 
@@ -126,7 +136,7 @@ This information will be automatically extracted and shown right in the merge re
 
 CAUTION: **Caution:**
 On self-managed instances, if a malicious actor compromises the Code Quality job
-definition they will be able to execute privileged Docker commands on the Runner
+definition they will be able to execute privileged Docker commands on the runner
 host. Having proper access control policies mitigates this attack vector by
 allowing access only to trusted actors.
 
@@ -276,7 +286,7 @@ This adds SonarJava to the `plugins:` section of the [default `.codeclimate.yml`
 included in your project.
 
 Changes to the `plugins:` section do not affect the `exclude_patterns` section of the
-defeault `.codeclimate.yml`. See the Code Climate documentation for
+default `.codeclimate.yml`. See the Code Climate documentation for
 [excluding files and folders](https://docs.codeclimate.com/docs/excluding-files-and-folders)
 for more details.
 
diff --git a/doc/user/project/merge_requests/getting_started.md b/doc/user/project/merge_requests/getting_started.md
index c7cabf3c73b..a0be32e0708 100644
--- a/doc/user/project/merge_requests/getting_started.md
+++ b/doc/user/project/merge_requests/getting_started.md
@@ -53,7 +53,7 @@ When you start a new merge request, you can immediately include the following
 options, or add them later by clicking the **Edit** button on the merge
 request's page at the top-right side:
 
-- [Assign](#assignee) the merge request to a colleague for review. With GitLab Starter and higher tiers, you can [assign it to more than one person at a time](#multiple-assignees-starter).
+- [Assign](#assignee) the merge request to a colleague for review. With GitLab Starter and higher tiers, you can [assign it to more than one person at a time](#multiple-assignees).
 - Set a [milestone](../milestones/index.md) to track time-sensitive changes.
 - Add [labels](../labels.md) to help contextualize and filter your merge requests over time.
 - Require [approval](merge_request_approvals.md) from your team. **(STARTER)**
diff --git a/doc/user/project/merge_requests/img/browser_performance_testing.png b/doc/user/project/merge_requests/img/browser_performance_testing.png
index 016abb89f7c..a3d7022bcfc 100644
--- a/doc/user/project/merge_requests/img/browser_performance_testing.png
+++ b/doc/user/project/merge_requests/img/browser_performance_testing.png
diff --git a/doc/user/project/merge_requests/img/update_approval_rule_v13_4.png b/doc/user/project/merge_requests/img/update_approval_rule_v13_4.png
new file mode 100644
index 00000000000..af713b48140
--- /dev/null
+++ b/doc/user/project/merge_requests/img/update_approval_rule_v13_4.png
diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md
index a9ee9d8e507..69276f0677b 100644
--- a/doc/user/project/merge_requests/index.md
+++ b/doc/user/project/merge_requests/index.md
@@ -19,7 +19,7 @@ A. Consider you're a software developer working in a team:
 1. You checkout a new branch, and submit your changes through a merge request
 1. You gather feedback from your team
 1. You work on the implementation optimizing code with [Code Quality reports](code_quality.md)
-1. You verify your changes with [JUnit test reports](../../../ci/junit_test_reports.md) in GitLab CI/CD
+1. You verify your changes with [Unit test reports](../../../ci/unit_test_reports.md) in GitLab CI/CD
 1. You avoid using dependencies whose license is not compatible with your project with [License Compliance reports](../../compliance/license_compliance/index.md) **(ULTIMATE)**
 1. You request the [approval](merge_request_approvals.md) from your manager **(STARTER)**
 1. Your manager:
diff --git a/doc/user/project/merge_requests/load_performance_testing.md b/doc/user/project/merge_requests/load_performance_testing.md
index 97f4f202ab3..daebd71e14f 100644
--- a/doc/user/project/merge_requests/load_performance_testing.md
+++ b/doc/user/project/merge_requests/load_performance_testing.md
@@ -28,7 +28,7 @@ GET calls to a popular API endpoint in your application to see how it performs.
 ## How Load Performance Testing works
 
 First, define a job in your `.gitlab-ci.yml` file that generates the
-[Load Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsload_performance-premium).
+[Load Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsload_performance).
 GitLab checks this report, compares key load performance metrics
 between the source and target branches, and then shows the information in a merge request widget:
 
@@ -102,7 +102,7 @@ job.
 
 An example configuration workflow:
 
-1. Set up a GitLab Runner that can run Docker containers, such as a Runner using the
+1. Set up GitLab Runner to run Docker containers, like the
    [Docker-in-Docker workflow](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
 1. Configure the default Load Performance Testing CI job in your `.gitlab-ci.yml` file.
    You need to include the template and configure it with variables:
@@ -140,7 +140,7 @@ For example, you can override the duration of the test with a CLI option:
 
 GitLab only displays the key performance metrics in the MR widget if k6's results are saved
 via [summary export](https://k6.io/docs/results-visualization/json#summary-export)
-as a [Load Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsload_performance-premium).
+as a [Load Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsload_performance).
 The latest Load Performance artifact available is always used, using the
 summary values from the test.
 
@@ -152,17 +152,20 @@ The CI/CD YAML configuration example above works for testing against static envi
 but it can be extended to work with [review apps](../../../ci/review_apps) or
 [dynamic environments](../../../ci/environments) with a few extra steps.
 
-The best approach is to capture the dynamic URL into a custom environment variable that
-is then [inherited](../../../ci/variables/README.md#inherit-environment-variables)
-by the `load_performance` job. The k6 test script to be run should then be configured to
-use that environment URL, such as: ``http.get(`${__ENV.ENVIRONMENT_URL`})``.
+The best approach is to capture the dynamic URL in a [`.env` file](https://docs.docker.com/compose/env-file/)
+as a job artifact to be shared, then use a custom environment variable we've provided named `K6_DOCKER_OPTIONS`
+to configure the k6 Docker container to use the file. With this, k6 can then use any
+environment variables from the `.env` file in scripts using standard JavaScript,
+such as: ``http.get(`${__ENV.ENVIRONMENT_URL`})``.
 
 For example:
 
 1. In the `review` job:
-    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 an [`artifacts:reports:dotenv` report](../../../ci/variables/README.md#inherit-environment-variables).
-1. Set the `load_performance` job to depend on the review job, so it inherits the environment variable.
+   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. Configure the k6 test script to use the environment variable in it's steps.
 
 Your `.gitlab-ci.yml` file might be similar to:
@@ -184,15 +187,16 @@ review:
     - run_deploy_script
     - echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env
   artifacts:
-    reports:
-      dotenv:
-        review.env
+    paths:
+      - review.env
   rules:
     - if: '$CI_COMMIT_BRANCH'  # Modify to match your pipeline rules, or use `only/except` if needed.
 
 load_performance:
   dependencies:
     - review
+  variables:
+    K6_DOCKER_OPTIONS: '--env-file review.env'
   rules:
     - if: '$CI_COMMIT_BRANCH'  # Modify to match your pipeline rules, or use `only/except` if needed.
 ```
diff --git a/doc/user/project/merge_requests/merge_request_approvals.md b/doc/user/project/merge_requests/merge_request_approvals.md
index 407fc5db425..185ab0e6298 100644
--- a/doc/user/project/merge_requests/merge_request_approvals.md
+++ b/doc/user/project/merge_requests/merge_request_approvals.md
@@ -36,7 +36,7 @@ Required approvals enable multiple use cases:
   database, and so on, for all proposed code changes.
 - Designating [Code Owners as eligible approvers](#code-owners-as-eligible-approvers),
   determined by the files changed in a merge request.
-- [Requiring approval from a security team](#security-approvals-in-merge-requests-ultimate)
+- [Requiring approval from a security team](#security-approvals-in-merge-requests)
   before merging code that could introduce a vulnerability.**(ULTIMATE)**
 
 ### Approval Rules
@@ -52,7 +52,7 @@ minimum number of required approvers can still be set in the [project settings f
 
 You can opt to define one single rule to approve a merge request among the available rules
 or choose more than one. Single approval rules are available in GitLab Starter and higher tiers,
-while [multiple approval rules](#multiple-approval-rules-premium) are available in
+while [multiple approval rules](#multiple-approval-rules) are available in
 [GitLab Premium](https://about.gitlab.com/pricing/) and above.
 
 NOTE: **Note:**
@@ -61,6 +61,8 @@ group is public.
 
 #### Eligible Approvers
 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10294) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.3, when an eligible approver comments on a merge request, it appears in the **Commented by** column of the Approvals widget.
+
 The following users can approve merge requests:
 
 - Users who have been added as approvers at the project or merge request levels with
@@ -84,8 +86,7 @@ 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)
 are enabled on the project settings.
 
-[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10294) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.3,
-when an eligible approver comments on a merge request, it appears in the **Commented by** column of the Approvals widget,
+When an eligible approver comments on a merge request, it appears in the **Commented by** column of the Approvals widget,
 indicating who has engaged in the merge request review. Authors and reviewers can also easily identify who they should reach out
 to if they have any questions or inputs about the content of the merge request.
 
@@ -118,7 +119,30 @@ users with Developer or higher permissions, as well as by Code Owners,
 indistinguishably.
 
 Alternatively, you can **require**
-[Code Owner's approvals for Protected Branches](../protected_branches.md#protected-branches-approval-by-code-owners-premium). **(PREMIUM)**
+[Code Owner's approvals for Protected Branches](../protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)**
+
+#### Merge Request approval segregation of duties
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40491) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.4.
+
+Managers or operators with [Reporter permissions](../../permissions.md#project-members-permissions)
+to a project sometimes need to be required approvers of a merge request,
+before a merge to a protected branch begins. These approvers aren't allowed
+to push or merge code to any branches.
+
+To enable this access:
+
+1. [Create a new group](../../group/index.md#create-a-new-group), and then
+   [add the user to the group](../../group/index.md#add-users-to-a-group),
+   ensuring you select the Reporter role for the user.
+1. [Share the project with your group](../members/share_project_with_groups.md#sharing-a-project-with-a-group-of-users),
+   based on the Reporter role.
+1. Navigate to your project's **Settings > General**, and in the
+   **Merge request approvals** section, click **Expand**.
+1. [Add the group](../../group/index.md#create-a-new-group) to the permission list
+   for the protected branch.
+
+![Update approval rule](img/update_approval_rule_v13_4.png)
 
 #### Adding / editing a default approval rule
 
@@ -204,7 +228,7 @@ Alternatively, you can select a very specific protected branch from the **Target
 
 ![Scoped to Protected Branch](img/scoped_to_protected_branch_v12_8.png)
 
-To enable this configuration, see [Code Owner’s approvals for protected branches](../protected_branches.md#protected-branches-approval-by-code-owners-premium).
+To enable this configuration, see [Code Owner’s approvals for protected branches](../protected_branches.md#protected-branches-approval-by-code-owners).
 
 ### Adding or removing an approval
 
@@ -242,9 +266,9 @@ The project settings for Merge request approvals are found by going to
 
 #### Prevent overriding default approvals
 
-By default, users are able to edit the approval rules in merge requests. If disabled,
-the approval rules for all new merge requests will be determined by the
-[default approval rules](#adding--editing-a-default-approval-rule). To disable this feature:
+Regardless of the approval rules you choose for your project, users can edit them in every merge
+request, overriding the rules you set as [default](#adding--editing-a-default-approval-rule).
+To prevent that from happening:
 
 1. Uncheck the **Can override approvers and approvals required per merge request** checkbox.
 1. Click **Save changes**.
@@ -267,14 +291,15 @@ from the UI. However, approvals will be reset if the target branch is changed.
 
 > [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. Authors
-also need to be included in the approvers list in order to be able to
-approve their merge request. To enable this feature:
+By default, projects are configured to prevent merge requests from being approved by
+their own authors. To change this setting:
 
-1. Uncheck the **Prevent approval of merge requests by merge request author** checkbox,
-   which is enabled by default.
+1. Go to your project's **Settings > General**, expand **Merge request approvals**.
+1. Uncheck the **Prevent approval of merge requests by merge request author** checkbox.
 1. Click **Save changes**.
 
+Note that users can edit the approval rules in every merge request and override pre-defined settings unless it's set [**not to allow** overrides](#prevent-overriding-default-approvals).
+
 #### 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.
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 4e821145339..3a18cacde64 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
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: index, reference
 ---
 
-# Reviewing and managing merge requests
+# Reviewing and managing merge requests **(CORE)**
 
 Merge requests are the primary method of making changes to files in a GitLab project.
 Changes are proposed by [creating and submitting a merge request](creating_merge_requests.md),
@@ -67,13 +67,21 @@ list.
 
 ![Merge request diff file navigation](img/merge_request_diff_file_navigation.png)
 
+### Collapsed files in the Changes view
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/232820) in GitLab 13.4.
+
+When you review changes in the **Changes** tab, files with a large number of changes are collapsed
+to improve performance. When files are collapsed, a warning appears at the top of the changes.
+Click **Expand file** on any file to view the changes for that file.
+
 ### File-by-file diff navigation
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/222790) in GitLab 13.2.
 > - It's deployed behind a feature flag, enabled by default.
 > - It's recommended for production use.
 > - It's enabled on GitLab.com.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-file-by-file-diff-navigation-core-only).
+> - 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
@@ -156,7 +164,7 @@ in a Merge Request. To do so, click the **{comment}** **comment** icon in the gu
 > - It's enabled on GitLab.com.
 > - It can be disabled or enabled per-project.
 > - It's recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-multiline-comments-core-only). **(CORE ONLY)**
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-multiline-comments). **(CORE ONLY)**
 
 GitLab provides a way to select which lines of code a comment refers to. After starting a comment
 a dropdown selector is shown to select the first line that this comment refers to.
@@ -203,6 +211,11 @@ If there's an [environment](../../../ci/environments/index.md) and the applicati
 successfully deployed to it, the deployed environment and the link to the
 Review App will be shown as well.
 
+NOTE: **Note:**
+When the default branch (for example, `main`) is red due to a failed CI pipeline, the `merge` button
+When the pipeline fails in a merge request but it can be merged nonetheless,
+the **Merge** button will be colored in red.
+
 ### Post-merge pipeline status
 
 When a merge request is merged, you can see the post-merge pipeline status of
@@ -284,15 +297,37 @@ the command line.
 NOTE: **Note:**
 This section might move in its own document in the future.
 
-### Checkout merge requests locally
+### Copy the branch name for local checkout
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/23767) in GitLab 13.4.
+
+The merge request sidebar contains the branch reference for the source branch
+used to contribute changes for this merge request.
+
+To copy the branch reference into your clipboard, click the **Copy branch name** button
+(**{copy-to-clipboard}**) in the right sidebar. You can then use it to checkout the branch locally
+via command line by running `git checkout <branch-name>`.
+
+### Checkout merge requests locally through the `head` ref
 
 A merge request contains all the history from a repository, plus the additional
 commits added to the branch associated with the merge request. Here's a few
-tricks to checkout a merge request locally.
+ways to checkout a merge request locally.
 
 Please note that you can checkout a merge request locally even if the source
 project is a fork (even a private fork) of the target project.
 
+This relies on the merge request `head` ref (`refs/merge-requests/:iid/head`)
+that is available for each merge request. It allows checking out a merge
+request via its ID instead of its branch.
+
+[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223156) in GitLab
+13.4, 14 days after a merge request gets closed or merged, the merge request
+`head` ref will be deleted. This means that the merge request will not be available
+for local checkout via the merge request `head` ref anymore. The merge request
+can still be re-opened. Also, as long as the merge request's branch
+exists, you can still check out the branch as it won't be affected.
+
 #### Checkout locally by adding a Git alias
 
 Add the following alias to your `~/.gitconfig`:
diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md
index 7f752b2cc39..69a0dd6e84f 100644
--- a/doc/user/project/merge_requests/squash_and_merge.md
+++ b/doc/user/project/merge_requests/squash_and_merge.md
@@ -65,14 +65,27 @@ 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:
+on the merge request form. Users can select or unselect the checkbox at the moment
+they are creating the merge request:
 
 ![Squash commits checkbox on edit form](img/squash_edit_form.png)
 
-This can then be overridden at the time of accepting the merge request:
+After the merge request is submitted, Squash and Merge can still be enabled or disabled
+by editing the merge request description:
+
+1. Scroll to the top of the merge request page and click **Edit**.
+1. Scroll down to the end of the merge request form and select the checkbox
+**Squash commits when merge request is accepted**.
+
+This setting can then be overridden at the time of accepting the merge request.
+At the end of the merge request widget, next to the **Merge** button, the **Squash commits** checkbox
+can be either selected or unselected:
 
 ![Squash commits checkbox on accept merge request form](img/squash_mr_widget.png)
 
+Note that Squash and Merge might not be available depending on the project's configuration
+for [Squash Commit Options](#squash-commits-options).
+
 ## Commit metadata for squashed commits
 
 The squashed commit has the following metadata:
@@ -97,7 +110,7 @@ squashing can itself be considered equivalent to rebasing.
 > - It's enabled on GitLab.com.
 > - It can be enabled per project.
 > - It's recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-squash-commit-options-core-only). **(CORE ONLY)**
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-squash-commit-options). **(CORE ONLY)**
 
 With Squash Commits Options you can configure the behavior of Squash and Merge for your project.
 To set it up, navigate to your project's **Settings > General** and expand **Merge requests**.
@@ -133,7 +146,7 @@ To enable it:
 # Instance-wide
 Feature.enable(:squash_options)
 # or by project
-Feature.enable(:squash_options, Project.find(<project id>))
+Feature.enable(:squash_options, Project.find(<project ID>))
 ```
 
 To disable it:
@@ -142,7 +155,7 @@ To disable it:
 # Instance-wide
 Feature.disable(:squash_options)
 # or by project
-Feature.disable(:squash_options, Project.find(<project id>))
+Feature.disable(:squash_options, Project.find(<project ID>))
 ```
 
 <!-- ## Troubleshooting
diff --git a/doc/user/project/merge_requests/test_coverage_visualization.md b/doc/user/project/merge_requests/test_coverage_visualization.md
index 6751dde155c..56b5774f15b 100644
--- a/doc/user/project/merge_requests/test_coverage_visualization.md
+++ b/doc/user/project/merge_requests/test_coverage_visualization.md
@@ -8,9 +8,9 @@ type: reference, howto
 # Test Coverage Visualization **(CORE ONLY)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3708) in GitLab 12.9.
-> - It's deployed behind a feature flag, disabled by default.
-> - It's disabled on GitLab.com.
-> - It can be enabled or disabled per-project.
+> - [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)**
 
 With the help of [GitLab CI/CD](../../../ci/README.md), you can collect the test
@@ -76,11 +76,9 @@ test:
 
 ## Enabling the feature
 
-This feature comes with the `:coverage_report_view` feature flag disabled by
-default. It is disabled on GitLab.com. This feature is disabled due to some performance issues with very large
-data sets. When [the performance issue](https://gitlab.com/gitlab-org/gitlab/-/issues/211410)
-is resolved, the feature will be enabled by default. [GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
-can enable it for your instance. Test coverage visualization can be enabled or disabled per-project.
+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.
 
 To enable it:
 
diff --git a/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md b/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md
index e5ebc46d58f..b298c62a5e6 100644
--- a/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md
+++ b/doc/user/project/merge_requests/testing_and_reports_in_merge_requests.md
@@ -19,7 +19,7 @@ or link to useful information directly from merge requests:
 | [Code Quality](code_quality.md)                                                                        | Analyze your source code quality using the [Code Climate](https://codeclimate.com/) analyzer and show the Code Climate report right in the merge request widget area.                                     |
 | [Display arbitrary job artifacts](../../../ci/yaml/README.md#artifactsexpose_as)                       | Configure CI pipelines with the `artifacts:expose_as` parameter to directly link to selected [artifacts](../../../ci/pipelines/job_artifacts.md) in merge requests.                                                |
 | [GitLab CI/CD](../../../ci/README.md)                                                                  | Build, test, and deploy your code in a per-branch basis with built-in CI/CD.                                                                                                                              |
-| [JUnit test reports](../../../ci/junit_test_reports.md)                                                | Configure your CI jobs to use JUnit test reports, and let GitLab display a report on the merge request so that it’s easier and faster to identify the failure without having to check the entire job log. |
+| [Unit test reports](../../../ci/unit_test_reports.md)                                                  | Configure your CI jobs to use Unit test reports, and let GitLab display a report on the merge request so that it’s easier and faster to identify the failure without having to check the entire job log. |
 | [License Compliance](../../compliance/license_compliance/index.md) **(ULTIMATE)**                      | Manage the licenses of your dependencies. |
 | [Metrics Reports](../../../ci/metrics_reports.md) **(PREMIUM)**                                        | Display the Metrics Report on the merge request so that it's fast and easy to identify changes to important metrics.                                                                                      |
 | [Multi-Project pipelines](../../../ci/multi_project_pipelines.md) **(PREMIUM)**                        | When you set up GitLab CI/CD across multiple projects, you can visualize the entire pipeline, including all cross-project interdependencies.                                                              |