Add latest changes from gitlab-org/gitlab@15-2-stable-eev15.2.0-rc42

53 files changed, 2307 insertions, 308 deletions

diff --git a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
index 40b29ebb6ea..c536ff59b84 100644
--- a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
+++ b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
@@ -18,8 +18,13 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
    1. On the top menu, select **Projects > Create new project**.
    1. Select **Run CI/CD for external repository**.
    1. Select **Repository by URL**.
+   1. Fill in the fields with information from the repository in Bitbucket:
+      - For **Git repository URL**, use the URL from the **Clone this repository** panel in Bitbucket.
+      - Leave the username blank.
+      - You can generate and use a [Bitbucket App Password](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/) for the password field.
 
    GitLab imports the repository and enables [Pull Mirroring](../../user/project/repository/mirror/pull.md).
+   You can check that mirroring is working in the project by going to **Settings > Repository > Mirroring repositories**.
 
 1. In GitLab, create a
    [Personal Access Token](../../user/profile/personal_access_tokens.md)
diff --git a/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md b/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md
index 9af5218e058..aea7b492d4e 100644
--- a/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md
+++ b/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md
@@ -223,7 +223,7 @@ These variables are injected into the pipeline jobs and can access the ECS API.
    |`AWS_SECRET_ACCESS_KEY`|`<Secret access key of the deployer>`| For authenticating `aws` CLI. |
    |`AWS_DEFAULT_REGION`|`us-east-2`| For authenticating `aws` CLI. |
    |`CI_AWS_ECS_CLUSTER`|`ecs-demo`| The ECS cluster is accessed by `production_ecs` job. |
-   |`CI_AWS_ECS_SERVICE`|`ecs_demo`| The ECS service of the cluster is updated by `production_ecs` job. |
+   |`CI_AWS_ECS_SERVICE`|`ecs_demo`| The ECS service of the cluster is updated by `production_ecs` job. Ensure that this variable is scoped to the appropriate environment (`production`, `staging`, `review/*`). |
    |`CI_AWS_ECS_TASK_DEFINITION`|`ecs_demo`| The ECS task definition is updated by `production_ecs` job. |
 
 ### Make a change to the demo application
@@ -246,6 +246,55 @@ NOTE:
 ECS deploy jobs wait for the rollout to complete before exiting. To disable this behavior,
 set `CI_AWS_ECS_WAIT_FOR_ROLLOUT_COMPLETE_DISABLED` to a non-empty value.
 
+## Set up Review Apps
+
+To use [Review Apps](../../../development/testing_guide/review_apps.md) with ECS:
+
+1. Set up a new [service](#create-an-ecs-service).
+1. Use the `CI_AWS_ECS_SERVICE` variable to set the name.
+1. Set the environment scope to `review/*`.
+
+Only one Review App at a time can be deployed because this service is shared by all review apps.
+
+## Set up Security Testing
+
+### Configure SAST
+
+To use [SAST](../../../user/application_security/sast/index.md) with ECS, add the following to your `.gitlab-ci.yml` file:
+
+```yaml
+include:
+   - template: Security/SAST.gitlab-ci.yml
+```
+
+For more details and configuration options, see the [SAST documentation](../../../user/application_security/sast/index.md#configuration).
+
+### Configure DAST
+
+To use [DAST](../../../user/application_security/dast/index.md) on non-default branches, [set up review apps](#set-up-review-apps)
+and add the following to your `.gitlab-ci.yml` file:
+
+```yaml
+include:
+  - template: Security/DAST.gitlab-ci.yml
+```
+
+To use DAST on the default branch:
+
+1. Set up a new [service](#create-an-ecs-service). This service will be used to deploy a temporary
+DAST environment.
+1. Use the `CI_AWS_ECS_SERVICE` variable to set the name.
+1. Set the scope to the `dast-default` environment.
+1. Add the following to your `.gitlab-ci.yml` file:
+
+```yaml
+include:
+  - template: Security/DAST.gitlab-ci.yml
+  - template: Jobs/DAST-Default-Branch-Deploy.gitlab-ci.yml
+```
+
+For more details and configuration options, see the [DAST documentation](../../../user/application_security/dast/index.md).
+
 ## Further reading
 
 - If you're interested in more of the continuous deployments to clouds, see [cloud deployments](../index.md).
diff --git a/doc/ci/cloud_deployment/heroku.md b/doc/ci/cloud_deployment/heroku.md
new file mode 100644
index 00000000000..4e627675b01
--- /dev/null
+++ b/doc/ci/cloud_deployment/heroku.md
@@ -0,0 +1,32 @@
+---
+stage: Release
+group: Release
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Use GitLab CI/CD to deploy to Heroku
+
+You can deploy an application to Heroku by using GitLab CI/CD.
+
+## Prerequisites
+
+- A [Heroku](https://id.heroku.com/login) account.
+  Sign in with an existing Heroku account or create a new one.
+
+## Deploy to Heroku
+
+1. In Heroku:
+   1. Create an application and copy the application name.
+   1. Browse to **Account Settings** and copy the API key.
+1. In your GitLab project, create two [variables](../../ci/variables/index.md):
+   - `HEROKU_APP_NAME` for the application name.
+   - `HEROKU_PRODUCTION_KEY` for the API key
+1. Edit your `.gitlab-ci.yml` file to add the Heroku deployment command. This example uses the `dpl` gem for Ruby:
+
+   ```yaml
+   heroku_deploy:
+     stage: production
+     script:
+       - gem install dpl
+       - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_PRODUCTION_KEY
+   ```
diff --git a/doc/ci/cloud_deployment/index.md b/doc/ci/cloud_deployment/index.md
index c5be2328264..5df396e796e 100644
--- a/doc/ci/cloud_deployment/index.md
+++ b/doc/ci/cloud_deployment/index.md
@@ -93,7 +93,7 @@ To deploy to your ECS cluster:
    | Environment variable name      | Value                   |
    |:-------------------------------|:------------------------|
    | `CI_AWS_ECS_CLUSTER`           | The name of the AWS ECS cluster that you're targeting for your deployments. |
-   | `CI_AWS_ECS_SERVICE`           | The name of the targeted service tied to your AWS ECS cluster. |
+   | `CI_AWS_ECS_SERVICE`           | The name of the targeted service tied to your AWS ECS cluster. Ensure that this variable is scoped to the appropriate environment (`production`, `staging`, `review/*`). |
    | `CI_AWS_ECS_TASK_DEFINITION`   | If the task definition is in ECS, the name of the task definition tied to the service. |
    | `CI_AWS_ECS_TASK_DEFINITION_FILE` | If the task definition is a JSON file in GitLab, the filename, including the path. For example, `ci/aws/my_task_definition.json`. If the name of the task definition in your JSON file is the same name as an existing task definition in ECS, then a new revision is created when CI/CD runs. Otherwise, a brand new task definition is created, starting at revision 1. |
 
diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md
index b13bd041d46..6ffa68e4873 100644
--- a/doc/ci/environments/index.md
+++ b/doc/ci/environments/index.md
@@ -406,8 +406,11 @@ When you stop an environment:
   to the list of **Stopped** environments.
 - An [`on_stop` action](../yaml/index.md#environmenton_stop), if defined, is executed.
 
-Dynamic environments stop automatically when their associated branch is
-deleted.
+There are multiple ways to clean up [dynamic environments](#create-a-dynamic-environment):
+
+- If you use [merge request pipelines](../pipelines/merge_request_pipelines.md), GitLab stops an environment [when a merge request is merged or closed](#stop-an-environment-when-a-merge-request-is-merged-or-closed).
+- If you do _NOT_ use [merge request pipelines](../pipelines/merge_request_pipelines.md), GitLab stops an environment [when the associated feature branch is deleted](#stop-an-environment-when-a-branch-is-deleted).
+- If you set [an expiry period to an environment](../yaml/index.md#environmentauto_stop_in), GitLab stops an environment [when it's expired](#stop-an-environment-after-a-certain-time-period).
 
 #### Stop an environment when a branch is deleted
 
@@ -425,8 +428,6 @@ deploy_review:
     name: review/$CI_COMMIT_REF_SLUG
     url: https://$CI_ENVIRONMENT_SLUG.example.com
     on_stop: stop_review
-  rules:
-    - if: $CI_MERGE_REQUEST_ID
 
 stop_review:
   stage: deploy
@@ -435,9 +436,7 @@ stop_review:
   environment:
     name: review/$CI_COMMIT_REF_SLUG
     action: stop
-  rules:
-    - if: $CI_MERGE_REQUEST_ID
-      when: manual
+  when: manual
 ```
 
 Both jobs must have the same [`rules`](../yaml/index.md#rules)
@@ -455,6 +454,39 @@ try to check out the code after the branch is deleted.
 
 Read more in the [`.gitlab-ci.yml` reference](../yaml/index.md#environmenton_stop).
 
+#### Stop an environment when a merge request is merged or closed
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/60885) in GitLab 11.10.
+
+You can configure environments to stop when a merge request is merged or closed.
+This stop trigger is automatically enabled when you use [merge request pipelines](../pipelines/merge_request_pipelines.md).
+
+The following example shows a `deploy_review` job that calls a `stop_review` job
+to clean up and stop the environment.
+
+```yaml
+deploy_review:
+  stage: deploy
+  script:
+    - echo "Deploy a review app"
+  environment:
+    name: review/$CI_COMMIT_REF_SLUG
+    on_stop: stop_review
+  rules:
+    - if: $CI_MERGE_REQUEST_ID
+
+stop_review:
+  stage: deploy
+  script:
+    - echo "Remove review app"
+  environment:
+    name: review/$CI_COMMIT_REF_SLUG
+    action: stop
+  rules:
+    - if: $CI_MERGE_REQUEST_ID
+      when: manual
+```
+
 #### Stop an environment when another job is finished
 
 You can set an environment to stop when another job is finished.
@@ -642,6 +674,18 @@ To delete a stopped environment in the GitLab UI:
 1. Next to the environment you want to delete, select **Delete environment**.
 1. On the confirmation dialog box, select **Delete environment**.
 
+#### Delete an active environment without running a stop job
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225794) in GitLab 15.1.
+
+You can delete an active environment without running a stop job.
+This is useful when you have an active environment, but the corresponding `action: stop` job can't run or succeed for some reason.
+
+To delete an active environment:
+
+1. Execute the [Stop an environment API](../../api/environments.md#stop-an-environment) while specifying `force=true`.
+1. Execute the [Delete an environment API](../../api/environments.md#delete-an-environment).
+
 ### Access an environment for preparation or verification purposes
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208655) in GitLab 13.2.
diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
index 389429f3f0f..90cbcb9e240 100644
--- a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
+++ b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
@@ -33,29 +33,30 @@ Each job has JSON Web Token (JWT) provided as CI/CD variable named `CI_JOB_JWT`.
 
 The following fields are included in the JWT:
 
-| Field                   | When   | Description |
-| ----------------------- | ------ | ----------- |
-| `jti`                   | Always | Unique identifier for this token |
-| `iss`                   | Always | Issuer, the domain of your GitLab instance |
-| `iat`                   | Always | Issued at |
-| `nbf`                   | Always | Not valid before |
-| `exp`                   | Always | Expires at |
-| `sub`                   | Always | Subject (job ID) |
-| `namespace_id`          | Always | Use this to scope to group or user level namespace by ID |
-| `namespace_path`        | Always | Use this to scope to group or user level namespace by path |
-| `project_id`            | Always | Use this to scope to project by ID |
-| `project_path`          | Always | Use this to scope to project by path |
-| `user_id`               | Always | ID of the user executing the job |
-| `user_login`            | Always | Username of the user executing the job |
-| `user_email`            | Always | Email of the user executing the job |
-| `pipeline_id`           | Always | ID of this pipeline |
-| `pipeline_source`       | Always | [Pipeline source](../../jobs/job_control.md#common-if-clauses-for-rules) |
-| `job_id`                | Always | ID of this job |
-| `ref`                   | Always | Git ref for this job |
-| `ref_type`              | Always | Git ref type, either `branch` or `tag` |
-| `ref_protected`         | Always | `true` if this Git ref is protected, `false` otherwise |
-| `environment`           | Job is creating a deployment | Environment this job deploys to ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294440) in GitLab 13.9) |
-| `environment_protected` | Job is creating a deployment |`true` if deployed environment is protected, `false` otherwise ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294440) in GitLab 13.9) |
+| Field                   | When                         | Description                                                                                                                                                                                          |
+|-------------------------|------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `jti`                   | Always                       | Unique identifier for this token                                                                                                                                                                     |
+| `iss`                   | Always                       | Issuer, the domain of your GitLab instance                                                                                                                                                           |
+| `iat`                   | Always                       | Issued at                                                                                                                                                                                            |
+| `nbf`                   | Always                       | Not valid before                                                                                                                                                                                     |
+| `exp`                   | Always                       | Expires at                                                                                                                                                                                           |
+| `sub`                   | Always                       | Subject (job ID)                                                                                                                                                                                     |
+| `namespace_id`          | Always                       | Use this to scope to group or user level namespace by ID                                                                                                                                             |
+| `namespace_path`        | Always                       | Use this to scope to group or user level namespace by path                                                                                                                                           |
+| `project_id`            | Always                       | Use this to scope to project by ID                                                                                                                                                                   |
+| `project_path`          | Always                       | Use this to scope to project by path                                                                                                                                                                 |
+| `user_id`               | Always                       | ID of the user executing the job                                                                                                                                                                     |
+| `user_login`            | Always                       | Username of the user executing the job                                                                                                                                                               |
+| `user_email`            | Always                       | Email of the user executing the job                                                                                                                                                                  |
+| `pipeline_id`           | Always                       | ID of this pipeline                                                                                                                                                                                  |
+| `pipeline_source`       | Always                       | [Pipeline source](../../jobs/job_control.md#common-if-clauses-for-rules)                                                                                                                             |
+| `job_id`                | Always                       | ID of this job                                                                                                                                                                                       |
+| `ref`                   | Always                       | Git ref for this job                                                                                                                                                                                 |
+| `ref_type`              | Always                       | Git ref type, either `branch` or `tag`                                                                                                                                                               |
+| `ref_protected`         | Always                       | `true` if this Git ref is protected, `false` otherwise                                                                                                                                               |
+| `environment`           | Job specifies an environment | Environment this job specifies ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294440) in GitLab 13.9)                                                                                   |
+| `environment_protected` | Job specifies an environment | `true` if specified environment is protected, `false` otherwise ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294440) in GitLab 13.9)                                                  |
+| `deployment_tier`       | Job specifies an environment | [Deployment tier](../../environments/index.md#deployment-tier-of-environments) of environment this job specifies ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363590) in GitLab 15.2) |
 
 Example JWT payload:
 
diff --git a/doc/ci/examples/index.md b/doc/ci/examples/index.md
index 0fc7b06a584..77591ad2ca6 100644
--- a/doc/ci/examples/index.md
+++ b/doc/ci/examples/index.md
@@ -24,11 +24,11 @@ The following table lists examples with step-by-step tutorials that are containe
 
 | Use case                      | Resource |
 |-------------------------------|----------|
-| Browser performance testing   | [Browser Performance Testing with the Sitespeed.io container](../../user/project/merge_requests/browser_performance_testing.md). |
+| Browser performance testing   | [Browser Performance Testing with the Sitespeed.io container](../testing/browser_performance_testing.md). |
 | Deployment with Dpl           | [Using `dpl` as deployment tool](deployment/index.md). |
 | GitLab Pages                  | See the [GitLab Pages](../../user/project/pages/index.md) documentation for a complete example of deploying a static site. |
 | End-to-end testing            | [End-to-end testing with GitLab CI/CD and WebdriverIO](end_to_end_testing_webdriverio/index.md). |
-| Load performance testing      | [Load Performance Testing with the k6 container](../../user/project/merge_requests/load_performance_testing.md). |
+| Load performance testing      | [Load Performance Testing with the k6 container](../testing/load_performance_testing.md). |
 | Multi project pipeline        | [Build, test deploy using multi project pipeline](https://gitlab.com/gitlab-examples/upstream-project). |
 | npm with semantic-release     | [Publish npm packages to the GitLab Package Registry using semantic-release](semantic-release.md). |
 | PHP with Laravel, Envoy       | [Test and deploy Laravel applications with GitLab CI/CD and Envoy](laravel_with_gitlab_and_envoy/index.md). |
@@ -95,6 +95,7 @@ choose one of these templates:
 - [Rust (`Rust.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Rust.gitlab-ci.yml)
 - [Scala (`Scala.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Scala.gitlab-ci.yml)
 - [Swift (`Swift.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Swift.gitlab-ci.yml)
+- [Terraform (`Terraform.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.gitlab-ci.yml)
 - [Terraform (`Terraform.latest.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.latest.gitlab-ci.yml)
 
 If a programming language or framework template is not in this list, you can contribute
diff --git a/doc/ci/index.md b/doc/ci/index.md
index 4fe2dee32bf..80752830b85 100644
--- a/doc/ci/index.md
+++ b/doc/ci/index.md
@@ -83,8 +83,8 @@ GitLab CI/CD features, grouped by DevOps stage, include:
 | [ChatOps](chatops/index.md)                                                                  | Trigger CI jobs from chat, with results sent back to the channel. |
 | [Connect to cloud services](cloud_services/index.md)                                         | Connect to cloud providers using OpenID Connect (OIDC) to retrieve temporary credentials to access services or secrets. |
 | **Verify**                                                                                   |             |
-| [Browser Performance Testing](../user/project/merge_requests/browser_performance_testing.md) | Quickly determine the browser performance impact of pending code changes. |
-| [Load Performance Testing](../user/project/merge_requests/load_performance_testing.md)       | Quickly determine the server performance impact of pending code changes. |
+| [Browser Performance Testing](testing/browser_performance_testing.md)                        | Quickly determine the browser performance impact of pending code changes. |
+| [Load Performance Testing](testing/load_performance_testing.md)                              | Quickly determine the server performance impact of pending code changes. |
 | [CI services](services/index.md)                                                             | Link Docker containers with your base image. |
 | [GitLab CI/CD for external repositories](ci_cd_for_external_repos/index.md)                  | Get the benefits of GitLab CI/CD combined with repositories in GitHub and Bitbucket Cloud. |
 | [Interactive Web Terminals](interactive_web_terminal/index.md)                               | Open an interactive web terminal to debug the running jobs. |
@@ -101,7 +101,7 @@ GitLab CI/CD features, grouped by DevOps stage, include:
 | [GitLab Releases](../user/project/releases/index.md)                                         | Add release notes to Git tags. |
 | [Cloud deployment](cloud_deployment/index.md)                                                | Deploy your application to a main cloud provider. |
 | **Secure**                                                                                   |             |
-| [Code Quality](../user/project/merge_requests/code_quality.md)                               | Analyze your source code quality. |
+| [Code Quality](testing/code_quality.md)                                                      | Analyze your source code quality. |
 | [Container Scanning](../user/application_security/container_scanning/index.md)               | Check your Docker containers for known vulnerabilities. |
 | [Dependency Scanning](../user/application_security/dependency_scanning/index.md)             | Analyze your dependencies for known vulnerabilities. |
 | [License Compliance](../user/compliance/license_compliance/index.md)                         | Search your project dependencies for their licenses. |
diff --git a/doc/ci/jobs/index.md b/doc/ci/jobs/index.md
index 1f7a7436c0a..fd6afb1a0ad 100644
--- a/doc/ci/jobs/index.md
+++ b/doc/ci/jobs/index.md
@@ -45,9 +45,6 @@ Clicking an individual job shows you its job log, and allows you to:
 
 ### View all jobs in a project
 
-> - An improved view was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/293862) in GitLab 14.10, [with a flag](../../administration/feature_flags.md) named `jobs_table_vue`. Disabled by default.
-> - The job status filter was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82539) in GitLab 14.10, [with a flag](../../administration/feature_flags.md) named `jobs_table_vue_search`. Disabled by default.
-
 To view the full list of jobs that ran in a project:
 
 1. On the top bar, select **Menu > Projects** and find the project.
@@ -136,9 +133,9 @@ jobs. Select to expand them.
 To create a group of jobs, in the [CI/CD pipeline configuration file](../yaml/index.md),
 separate each job name with a number and one of the following:
 
-- A slash (`/`), for example, `test 1/3`, `test 2/3`, `test 3/3`.
-- A colon (`:`), for example, `test 1:3`, `test 2:3`, `test 3:3`.
-- A space, for example `test 0 3`, `test 1 3`, `test 2 3`.
+- A slash (`/`), for example, `slash-test 1/3`, `slash-test 2/3`, `slash-test 3/3`.
+- A colon (`:`), for example, `colon-test 1:3`, `colon-test 2:3`, `colon-test 3:3`.
+- A space, for example `space-test 0 3`, `space-test 1 3`, `space-test 2 3`.
 
 You can use these symbols interchangeably.
 
@@ -358,7 +355,7 @@ Add `[collapsed=true]` after the section name and before the `\r`. The section e
 remains unchanged:
 
 - Section start marker with `[collapsed=true]`: `\e[0Ksection_start:UNIX_TIMESTAMP:SECTION_NAME[collapsed=true]\r\e[0K` + `TEXT_OF_SECTION_HEADER`
-- Section end marker: `section_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K`
+- Section end marker: `\e[0Ksection_end:UNIX_TIMESTAMP:SECTION_NAME\r\e[0K`
 
 Add the updated section start text to the CI configuration. For example,
 using `echo`:
diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md
index 83747f36597..24133fe9a9b 100644
--- a/doc/ci/jobs/job_control.md
+++ b/doc/ci/jobs/job_control.md
@@ -547,25 +547,29 @@ You can use [protected branches](../../user/project/protected_branches.md) to mo
 
 ### Types of manual jobs
 
-Manual jobs can be either optional or blocking:
-
-- **Optional**: The default setting for manual jobs.
-  - They have [`allow_failure: true`](../yaml/index.md#allow_failure) by default.
-  - The status does not contribute to the overall pipeline status. A pipeline can
-    succeed even if all of its manual jobs fail.
-- **Blocking**: An optional setting for manual jobs.
-  - Add `allow_failure: false` to the job configuration.
-  - The pipeline stops at the stage where the job is defined. To let the pipeline
-    continue running, [run the manual job](#run-a-manual-job).
-  - Merge requests in projects with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
-    enabled can't be merged with a blocked pipeline. Blocked pipelines show a status
-    of **blocked**.
+Manual jobs can be either optional or blocking.
 
-### Run a manual job
+In optional manual jobs:
+
+- [`allow_failure`](../yaml/index.md#allow_failure) is `true`, which is the default
+  setting for jobs that have `when: manual` and no [`rules`](../yaml/index.md#rules),
+  or `when: manual` defined outside of `rules`.
+- The status does not contribute to the overall pipeline status. A pipeline can
+  succeed even if all of its manual jobs fail.
+
+In blocking manual jobs:
 
-To run a manual job, you must have permission to merge to the assigned branch.
+- `allow_failure` is `false`, which is the default setting for jobs that have `when: manual`
+  defined inside [`rules`](../yaml/index.md#rules).
+- The pipeline stops at the stage where the job is defined. To let the pipeline
+  continue running, [run the manual job](#run-a-manual-job).
+- Merge requests in projects with [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
+  enabled can't be merged with a blocked pipeline.
+- The pipeline shows a status of **blocked**.
+
+### Run a manual job
 
-To run a manual job:
+To run a manual job, you must have permission to merge to the assigned branch:
 
 1. Go to the pipeline, job, [environment](../environments/index.md#configure-manual-deployments),
    or deployment view.
diff --git a/doc/ci/metrics_reports.md b/doc/ci/metrics_reports.md
index 03869a639f1..c3ab3392f36 100644
--- a/doc/ci/metrics_reports.md
+++ b/doc/ci/metrics_reports.md
@@ -1,68 +1,11 @@
 ---
-stage: Verify
-group: Pipeline Insights
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+redirect_to: 'testing/metrics_reports.md'
+remove_date: '2022-08-31'
 ---
 
-# Metrics Reports **(PREMIUM)**
+This document was moved to [another location](testing/metrics_reports.md).
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9788) in GitLab 11.10. Requires GitLab Runner 11.10 and above.
-
-GitLab provides a lot of great reporting tools for things like [merge requests](../user/project/merge_requests/index.md) - [Unit test reports](testing/unit_test_reports.md), [code quality](../user/project/merge_requests/code_quality.md), and performance tests. While JUnit is a great open framework for tests that "pass" or "fail", it is also important to see other types of metrics from a given change.
-
-You can configure your job to use custom Metrics Reports, and GitLab displays a report on the merge request so that it's easier and faster to identify changes without having to check the entire log.
-
-![Metrics Reports](img/metrics_reports_v13_0.png)
-
-## Use cases
-
-Consider the following examples of data that can use Metrics Reports:
-
-1. Memory usage
-1. Load testing results
-1. Code complexity
-1. Code coverage stats
-
-## How it works
-
-Metrics for a branch are read from the latest metrics report artifact (default filename: `metrics.txt`) as string values.
-
-For an MR, the values of these metrics from the feature branch are compared to the values from the target branch. Then they are displayed in the MR widget in this order:
-
-- Existing metrics with changed values.
-- Metrics that have been added by the MR. Marked with a **New** badge.
-- Metrics that have been removed by the MR. Marked with a **Removed** badge.
-- Existing metrics with unchanged values.
-
-## How to set it up
-
-Add a job that creates a [metrics report](yaml/artifacts_reports.md#artifactsreportsmetrics) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format.
-
-For example:
-
-```yaml
-metrics:
-  script:
-    - echo 'metric_name metric_value' > metrics.txt
-  artifacts:
-    reports:
-      metrics: metrics.txt
-```
-
-## Advanced Example
-
-An advanced example of an OpenMetrics text file (from the [Prometheus documentation](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-format-example))
-renders in the merge request widget as:
-
-![Metrics Reports Advanced](img/metrics_reports_advanced_v13_0.png)
-
-## Troubleshooting
-
-### Metrics reports did not change
-
-You can see `Metrics reports did not change` when trying to view metrics reports in merge requests. Reasons for this are:
-
-- The target branch for the merge request doesn't have a baseline metrics report for comparison.
-- You don't have GitLab license at the Premium tier or above.
-
-There is [an issue open](https://gitlab.com/gitlab-org/gitlab/-/issues/343065) to improve this message.
+<!-- This redirect file can be deleted after <2022-09-22>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/ci/migration/circleci.md b/doc/ci/migration/circleci.md
index b1c4c62c465..3b890458e56 100644
--- a/doc/ci/migration/circleci.md
+++ b/doc/ci/migration/circleci.md
@@ -289,8 +289,8 @@ Self-managed runners:
 GitLab.com shared runners:
 
 - Linux
-- Windows
-- [Planned: macOS](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/5720)
+- [Windows](../runners/saas/windows_saas_runner.md) ([Beta](../../policy/alpha-beta-support.md#beta-features)).
+- [macOS](../runners/saas/macos_saas_runner.md) ([Beta](../../policy/alpha-beta-support.md#beta-features)).
 
 ### Machine and specific build environments
 
diff --git a/doc/ci/pipeline_editor/index.md b/doc/ci/pipeline_editor/index.md
index d87b336224c..4fb2ec94d60 100644
--- a/doc/ci/pipeline_editor/index.md
+++ b/doc/ci/pipeline_editor/index.md
@@ -98,7 +98,7 @@ where:
 - [YAML `!reference` tags](../yaml/yaml_optimization.md#reference-tags) are also replaced
   with the linked configuration.
 
-Using `!refence` tags can cause nested configuration that display with
+Using `!reference` tags can cause nested configuration that display with
 multiple hyphens (`-`) in the expanded view. This behavior is expected, and the extra
 hyphens do not affect the job's execution. For example, this configuration and
 fully expanded version are both valid:
diff --git a/doc/ci/pipelines/cicd_minutes.md b/doc/ci/pipelines/cicd_minutes.md
index ff30d5701cc..1e862c87035 100644
--- a/doc/ci/pipelines/cicd_minutes.md
+++ b/doc/ci/pipelines/cicd_minutes.md
@@ -7,22 +7,33 @@ type: reference
 
 # CI/CD minutes quota **(PREMIUM)**
 
-[Shared runners](../runners/runners_scope.md#shared-runners) are shared with every project and group in a GitLab instance.
-When jobs run on shared runners, CI/CD minutes are used.
+Administrators can limit the amount of time that projects can use to run jobs on
+[shared runners](../runners/runners_scope.md#shared-runners) each month. This limit
+is tracked with a quota of CI/CD minutes.
 
-You can set limits on the number of CI/CD minutes that are used each month.
+By default, one minute of execution time by a single job uses
+one CI/CD minute. The total amount of CI/CD minutes used by a pipeline is
+[the sum of all its jobs' durations](#how-cicd-minute-usage-is-calculated).
+Jobs can run concurrently, so the total CI/CD minute usage can be higher than the
+end-to-end duration of a pipeline.
 
-- On GitLab.com, the quota of CI/CD minutes is set for each [namespace](../../user/group/index.md#namespaces),
-  and is determined by [your license tier](https://about.gitlab.com/pricing/).
-- On self-managed GitLab instances, the quota of CI/CD minutes for each namespace is set by administrators.
+On GitLab.com:
 
-In addition to the monthly quota, you can add more CI/CD minutes when needed.
+- CI/CD minutes quotas are enabled for both public and private projects, but public
+  projects [consume CI/CD minutes at a slower rate](#cost-factor).
+- The base monthly CI/CD minutes quota for a GitLab.com [namespace](../../user/group/index.md#namespaces)
+  is determined by its [license tier](https://about.gitlab.com/pricing/).
+- You can [purchase additional CI/CD minutes](#purchase-additional-cicd-minutes)
+  if you need more than the number of CI/CD minutes in your monthly quota.
 
-- On GitLab.com, you can [purchase additional CI/CD minutes](#purchase-additional-cicd-minutes).
-- On self-managed GitLab instances, administrators can [assign more CI/CD minutes](#set-the-quota-of-cicd-minutes-for-a-specific-namespace).
+On self-managed GitLab instances:
 
-[Specific runners](../runners/runners_scope.md#specific-runners)
-are not subject to a quota of CI/CD minutes.
+- CI/CD minutes quotas are disabled by default.
+- When enabled, CI/CD minutes quotas apply to private projects only.
+- Administrators can [assign more CI/CD minutes](#set-the-quota-of-cicd-minutes-for-a-specific-namespace)
+  if a namespace uses all the CI/CD minutes in its monthly quota.
+
+[Specific runners](../runners/runners_scope.md#specific-runners) are not subject to a quota of CI/CD minutes.
 
 ## Set the quota of CI/CD minutes for all namespaces
 
@@ -160,46 +171,43 @@ To purchase additional minutes for your personal namespace:
 After your payment is processed, the additional CI/CD minutes are added to your personal
 namespace.
 
-## How CI/CD minutes are calculated
-
-CI/CD minutes for individual jobs are calculated based on:
+## How CI/CD minute usage is calculated
 
-- The duration the job runs.
-- The visibility of the projects where the job runs.
-
-GitLab uses this formula to calculate CI/CD minutes consumed by a job:
+GitLab uses this formula to calculate the CI/CD minute usage of a job:
 
 ```plaintext
 Job duration * Cost factor
 ```
 
-- **Job duration**: The time, in seconds, that a job took to run on a shared runner.
-  It does not include time spent in `created` or `pending` status.
-- **Cost factor**: A number based on project visibility.
+- **Job duration**: The time, in seconds, that a job took to run on a shared runner,
+  not including time spent in the `created` or `pending` statuses.
+- [**Cost factor**](#cost-factor): A number based on project visibility.
 
-The number is transformed into minutes and added to the overall quota in the job's top-level namespace.
+The value is transformed into minutes and added to the count of used CI/CD minutes
+in the job's top-level namespace.
 
-For example:
+For example, if a user `alice` runs a pipeline:
 
-- A user, `alice`, runs a pipeline under the `gitlab-org` namespace.
-- The CI/CD minutes consumed by each job in the pipeline are added to the
-  overall consumption for the `gitlab-org` namespace, not the `alice` namespace.
-- If a pipeline runs for one of the personal projects for `alice`, the CI/CD minutes
-  are added to the overall consumption for the `alice` namespace.
+- Under the `gitlab-org` namespace, the CI/CD minutes used by each job in the pipeline are
+  added to the overall consumption for the `gitlab-org` namespace, not the `alice` namespace.
+- For one of the personal projects in their namespace, the CI/CD minutes are added
+  to the overall consumption for the `alice` namespace.
 
 The CI/CD minutes used by one pipeline is the total CI/CD minutes used by all the jobs
-that ran in the pipeline. The CI/CD minute usage for a pipeline can be higher than
-the duration of the pipeline if many jobs ran at the same time.
+that ran in the pipeline. Jobs can run concurrently, so the total CI/CD minutes usage
+can be higher than the end-to-end duration of a pipeline.
 
 ### Cost factor
 
-The cost factor for a job running on a shared runner is:
+The cost factors for jobs running on shared runners on GitLab.com are:
+
+- `0.008` for public projects, and projects in the [GitLab for Open Source program](../../subscriptions/index.md#gitlab-for-open-source).
+  For every 125 minutes of job execution time, you use 1 CI/CD minute.
+- `1` for internal and private projects.
+
+The cost factors on self-managed instances are:
 
-- `0.008` for public projects on GitLab SaaS, if [created 2021-07-17 or later](https://gitlab.com/gitlab-org/gitlab/-/issues/332708).
-  (For every 125 minutes of job time, you accrue 1 CI/CD minute.)
-- `0.008` for projects members of GitLab [Open Source program](../../subscriptions/index.md#gitlab-for-open-source).
-  (For every 125 minutes of job time, you accrue 1 CI/CD minute.)
-- `0` for public projects on GitLab self-managed instances, and for GitLab SaaS public projects created before 2021-07-17.
+- `0` for public projects, so they do not consume CI/CD minutes.
 - `1` for internal and private projects.
 
 ### Additional costs on GitLab SaaS
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index 76419e61661..08264170d52 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -40,7 +40,7 @@ A typical pipeline might consist of four stages, executed in the following order
 NOTE:
 If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/mirror/pull.md),
 you may need to enable pipeline triggering in your project's
-**Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.
+**Settings > Repository > Mirroring repositories > Trigger pipelines for mirror updates**.
 
 ## Types of pipelines
 
@@ -374,7 +374,7 @@ GitLab capitalizes the stages' names in the pipeline graphs.
 
 ### View full pipeline graph
 
-> - Visualization improvements [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276949) in GitLab 13.11.
+> Visualization improvements [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276949) in GitLab 13.11.
 
 The [pipeline details page](#view-pipelines) displays the full pipeline graph of
 all the jobs in the pipeline.
diff --git a/doc/ci/pipelines/job_artifacts.md b/doc/ci/pipelines/job_artifacts.md
index b0336d0499f..c8babe3320d 100644
--- a/doc/ci/pipelines/job_artifacts.md
+++ b/doc/ci/pipelines/job_artifacts.md
@@ -430,3 +430,24 @@ successful_test_job:
     paths:
       - bin/results
 ```
+
+### Error message `FATAL: invalid argument` when uploading a dotenv artifact on a windows runner
+
+The PowerShell `echo` command writes files with UCS-2 LE BOM (Byte Order Mark) encoding,
+but only UTF-8 is supported. If you try create the dotenv artifact with `echo`, it causes a
+`FATAL: invalid argument` error.
+
+Use PowerShell `Add-Content` instead, which uses UTF-8:
+
+```yaml
+test-job:
+  stage: test
+  tags:
+    - windows
+  script:
+    - echo "test job"
+    - Add-Content -Path build.env -Value "MY_ENV_VAR=true"
+  artifacts:
+    reports:
+      dotenv: build.env
+```
diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md
index e0fe59d1ab8..ac644628f3a 100644
--- a/doc/ci/pipelines/merge_trains.md
+++ b/doc/ci/pipelines/merge_trains.md
@@ -69,7 +69,6 @@ To enable merge trains:
 
 - You must have the Maintainer role.
 - You must be using [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) 11.9 or later.
-- In GitLab 13.0 and later, you need [Redis](https://redis.io/) 5.0 or later.
 - Your repository must be a GitLab repository, not an
   [external repository](../ci_cd_for_external_repos/index.md).
 
diff --git a/doc/ci/pipelines/merged_results_pipelines.md b/doc/ci/pipelines/merged_results_pipelines.md
index 9661d2f5263..777871a7c5f 100644
--- a/doc/ci/pipelines/merged_results_pipelines.md
+++ b/doc/ci/pipelines/merged_results_pipelines.md
@@ -6,7 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Merged results pipelines **(PREMIUM)**
 
-> [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/351192) from `pipelines for merged results` to `merged results pipelines` in GitLab 14.8.
+> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/351192) from `pipelines for merged results` to `merged results pipelines` in GitLab 14.8.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91849) in GitLab 15.1, merged results pipelines also run on [Draft merge requests](../../user/project/merge_requests/drafts.md).
 
 A *merged results pipeline* is a type of [merge request pipeline](merge_request_pipelines.md). It is a pipeline that runs against the results of the source and target branches merged together.
 
@@ -19,10 +20,7 @@ The pipeline runs against the target branch as it exists at the moment you run t
 Over time, while you're working in the source branch, the target branch might change.
 Any time you want to be sure the merged results are accurate, you should re-run the pipeline.
 
-Merged results pipelines can't run when:
-
-- The target branch has changes that conflict with the changes in the source branch.
-- The merge request is a [**Draft** merge request](../../user/project/merge_requests/drafts.md).
+Merged results pipelines can't run when the target branch has changes that conflict with the changes in the source branch.
 
 In these cases, the pipeline runs as a [merge request pipeline](merge_request_pipelines.md)
 and [is labeled as `merge request`](merge_request_pipelines.md#types-of-merge-request-pipelines).
diff --git a/doc/ci/pipelines/multi_project_pipelines.md b/doc/ci/pipelines/multi_project_pipelines.md
index 20184635e4a..dfbd2708d8d 100644
--- a/doc/ci/pipelines/multi_project_pipelines.md
+++ b/doc/ci/pipelines/multi_project_pipelines.md
@@ -188,7 +188,7 @@ Upstream pipelines take precedence over downstream ones. If there are two
 variables with the same name defined in both upstream and downstream projects,
 the ones defined in the upstream project take precedence.
 
-#### Pass CI/CD variables to a downstream pipeline by using variable inheritance
+#### Pass CI/CD variables to a downstream pipeline by using variable inheritance **(PREMIUM)**
 
 You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](../variables/index.md#pass-an-environment-variable-to-another-job) and [`needs:project`](../yaml/index.md#needsproject).
 
diff --git a/doc/ci/pipelines/pipeline_artifacts.md b/doc/ci/pipelines/pipeline_artifacts.md
index 3a1367f4a8c..07e1c8a6d99 100644
--- a/doc/ci/pipelines/pipeline_artifacts.md
+++ b/doc/ci/pipelines/pipeline_artifacts.md
@@ -10,7 +10,7 @@ Pipeline artifacts are files created by GitLab after a pipeline finishes. Pipeli
 different to [job artifacts](job_artifacts.md) because they are not explicitly managed by
 `.gitlab-ci.yml` definitions.
 
-Pipeline artifacts are used by the [test coverage visualization feature](../../user/project/merge_requests/test_coverage_visualization.md)
+Pipeline artifacts are used by the [test coverage visualization feature](../testing/test_coverage_visualization.md)
 to collect coverage information.
 
 ## Storage
diff --git a/doc/ci/pipelines/pipeline_efficiency.md b/doc/ci/pipelines/pipeline_efficiency.md
index 991b3aef76c..ad43895d7ef 100644
--- a/doc/ci/pipelines/pipeline_efficiency.md
+++ b/doc/ci/pipelines/pipeline_efficiency.md
@@ -75,7 +75,7 @@ The [Pipeline success and duration charts](index.md#pipeline-success-and-duratio
 give information about pipeline runtime and failed job counts.
 
 Tests like [unit tests](../testing/unit_test_reports.md), integration tests, end-to-end tests,
-[code quality](../../user/project/merge_requests/code_quality.md) tests, and others
+[code quality](../testing/code_quality.md) tests, and others
 ensure that problems are automatically found by the CI/CD pipeline. There could be many
 pipeline stages involved causing long runtimes.
 
@@ -174,7 +174,7 @@ to stop them from running:
 Ensure that errors are detected early in the CI/CD pipeline. A job that takes a very long
 time to complete keeps a pipeline from returning a failed status until the job completes.
 
-Design pipelines so that jobs that can [fail fast](../../user/project/merge_requests/fail_fast_testing.md)
+Design pipelines so that jobs that can [fail fast](../testing/fail_fast_testing.md)
 run earlier. For example, add an early stage and move the syntax, style linting,
 Git commit message verification, and similar jobs in there.
 
diff --git a/doc/ci/pipelines/pipelines_for_merged_results.md b/doc/ci/pipelines/pipelines_for_merged_results.md
deleted file mode 100644
index 0c3100a51f1..00000000000
--- a/doc/ci/pipelines/pipelines_for_merged_results.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: 'merged_results_pipelines.md'
-remove_date: '2022-04-27'
----
-
-This document was moved to [another location](merged_results_pipelines.md).
-
-<!-- This redirect file can be deleted after 2022-04-27. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 40daf154a5f..43f20bfa9ea 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -21,7 +21,7 @@ For public and internal projects, you can change who can see your:
 - Pipelines
 - Job output logs
 - Job artifacts
-- [Pipeline security dashboard](../../user/application_security/security_dashboard/index.md#view-vulnerabilities-in-a-pipeline)
+- [Pipeline security dashboard](../../user/application_security/vulnerability_report/pipeline.md#view-vulnerabilities-in-a-pipeline)
 
 To change the visibility of your pipelines and related features:
 
@@ -288,6 +288,9 @@ regular expression displayed in the settings. Available in GitLab 14.10 and earl
 
 The regular expression you need is in the **Test coverage parsing** field.
 
+If you need to retrieve the project coverage setting from many projects, you can
+[use the API to programmatically retrieve the setting](https://gitlab.com/gitlab-org/gitlab/-/issues/17633#note_945941397).
+
 <!-- end_remove -->
 
 ### Test coverage examples
diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index 3ebd38df8db..6dd03033926 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -287,6 +287,9 @@ can supply the ID by either:
 - Dynamically adding the `data-merge-request-id` value during the build of the app.
 - Supplying it manually through the visual review form in the app.
 
+If the ID is missing from the `script`, the visual review tool prompts you to enter the
+merge request ID before you can provide feedback.
+
 ### Authentication for Visual Reviews
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/42750#note_317271120) in GitLab 12.10.
diff --git a/doc/ci/runners/index.md b/doc/ci/runners/index.md
index 729de4d99d3..038bda4ab09 100644
--- a/doc/ci/runners/index.md
+++ b/doc/ci/runners/index.md
@@ -12,7 +12,7 @@ No configuration is required. Your jobs can run on:
 
 - [Linux runners](saas/linux_saas_runner.md).
 - [Windows runners](saas/windows_saas_runner.md) ([Beta](../../policy/alpha-beta-support.md#beta-features)).
-- [macOS runners](saas/macos_saas_runner.md) ([Limited Availability](../../policy/alpha-beta-support.md#limited-availability-la)).
+- [macOS runners](saas/macos_saas_runner.md) ([Beta](../../policy/alpha-beta-support.md#beta-features)).
 
 The number of minutes you can use on these runners depends on the
 [maximum number of CI/CD minutes](../pipelines/cicd_minutes.md)
diff --git a/doc/ci/runners/saas/macos_saas_runner.md b/doc/ci/runners/saas/macos_saas_runner.md
index 65404c89f9a..5a2d84b6996 100644
--- a/doc/ci/runners/saas/macos_saas_runner.md
+++ b/doc/ci/runners/saas/macos_saas_runner.md
@@ -4,9 +4,9 @@ group: Runner
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# SaaS runners on macOS (Limited Availability) **(PREMIUM SAAS)**
+# SaaS runners on macOS (Beta) **(PREMIUM SAAS)**
 
-SaaS runners on macOS are in [Limited Availability](../../../policy/alpha-beta-support.md#limited-availability-la) for approved open source programs and customers in Premium and Ultimate plans.
+SaaS runners on macOS are in [Beta](../../../policy/alpha-beta-support.md#beta-features) for approved open source programs and customers in Premium and Ultimate plans.
 
 SaaS runners on macOS provide an on-demand macOS build environment integrated with
 GitLab SaaS [CI/CD](../../../ci/index.md).
@@ -18,13 +18,15 @@ CI/CD minutes used on GitLab SaaS macOS runners are included in your CI/CD minut
 
 Refer to the CI/CD minutes [cost factor](../../../ci/pipelines/cicd_minutes.md#cost-factor) for the cost factor applied to the GitLab SaaS macOS runners.
 
+Jobs handled by macOS shared runners on GitLab.com **time out after 2 hours**, regardless of the timeout configured in a project.
+
 ## Access request process
 
-While in limited availability, to run CI jobs on the macOS runners, GitLab SaaS customer namespaces must be explicitly added to the macOS `allow-list`. Customers who participated in the beta have already been added.
+While in beta, to run CI jobs on the macOS runners, GitLab SaaS customer namespaces must be explicitly added to the macOS `allow-list`.
 
 After you have been added, you can use the macOS runners for any projects in your namespace.
 
-To request access, open a [limited availability access request](https://gitlab.com/gitlab-com/runner-saas-macos-limited-availability/-/issues/new).
+To request access, open an [access request](https://gitlab.com/gitlab-com/runner-saas-macos-limited-availability/-/issues/new).
 The expected turnaround for activation is two business days.
 
 ## Quickstart
diff --git a/doc/ci/services/index.md b/doc/ci/services/index.md
index 3ab814200fb..ba3f806c96e 100644
--- a/doc/ci/services/index.md
+++ b/doc/ci/services/index.md
@@ -353,7 +353,7 @@ while only booting up the tested service once.
 ```yaml
 access-service:
   stage: build
-  image: docker:19.03.1
+  image: docker:20.10.16
   services:
     - docker:dind                    # necessary for docker run
     - tutum/wordpress:latest
diff --git a/doc/ci/testing/accessibility_testing.md b/doc/ci/testing/accessibility_testing.md
new file mode 100644
index 00000000000..7940b27acf7
--- /dev/null
+++ b/doc/ci/testing/accessibility_testing.md
@@ -0,0 +1,76 @@
+---
+stage: Verify
+group: Pipeline Insights
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Accessibility testing **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25144) in GitLab 12.8.
+
+If your application offers a web interface, you can use
+[GitLab CI/CD](../index.md) to determine the accessibility
+impact of pending code changes.
+
+[Pa11y](https://pa11y.org/) is a free and open source tool for
+measuring the accessibility of web sites. GitLab integrates Pa11y into a
+[CI job template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml).
+The `a11y` job analyzes a defined set of web pages and reports
+accessibility violations, warnings, and notices in a file named
+`accessibility`.
+
+As of [GitLab 14.5](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73309), Pa11y uses
+[WCAG 2.1 rules](https://www.w3.org/TR/WCAG21/#new-features-in-wcag-2-1).
+
+## Accessibility merge request widget
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39425) in GitLab 13.0 behind the disabled [feature flag](../../administration/feature_flags.md) `:accessibility_report_view`.
+> - [Feature Flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/217372) in GitLab 13.1.
+
+GitLab displays an **Accessibility Report** in the merge request widget area:
+
+![Accessibility merge request widget](img/accessibility_mr_widget_v13_0.png)
+
+## Configure accessibility testing
+
+You can run Pa11y with GitLab CI/CD using the
+[GitLab Accessibility Docker image](https://gitlab.com/gitlab-org/ci-cd/accessibility).
+
+To define the `a11y` job for GitLab 12.9 and later:
+
+1. [Include](../yaml/index.md#includetemplate) the
+   [`Accessibility.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml)
+   from your GitLab installation.
+1. Add the following configuration to your `.gitlab-ci.yml` file.
+
+   ```yaml
+   stages:
+     - accessibility
+
+   variables:
+     a11y_urls: "https://about.gitlab.com https://gitlab.com/users/sign_in"
+
+   include:
+     - template: "Verify/Accessibility.gitlab-ci.yml"
+   ```
+
+1. Customize the `a11y_urls` variable to list the URLs of the web pages to test with Pa11y.
+
+The `a11y` job in your CI/CD pipeline generates these files:
+
+- One HTML report per URL listed in the `a11y_urls` variable.
+- One file containing the collected report data. In GitLab versions 12.11 and later, this
+  file is named `gl-accessibility.json`. In GitLab versions 12.10 and earlier, this file
+  is named [`accessibility.json`](https://gitlab.com/gitlab-org/ci-cd/accessibility/-/merge_requests/9).
+
+You can [view job artifacts in your browser](../pipelines/job_artifacts.md#download-job-artifacts).
+
+NOTE:
+For GitLab versions earlier than 12.9, use `include:remote` and
+link to the [current template in the default branch](https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml)
+
+NOTE:
+The job definition provided by the template does not support Kubernetes.
+
+You cannot pass configurations into Pa11y via CI configuration.
+To change the configuration, edit a copy of the template in your CI file.
diff --git a/doc/ci/testing/browser_performance_testing.md b/doc/ci/testing/browser_performance_testing.md
new file mode 100644
index 00000000000..260ecf6108d
--- /dev/null
+++ b/doc/ci/testing/browser_performance_testing.md
@@ -0,0 +1,242 @@
+---
+stage: Verify
+group: Pipeline Insights
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Browser Performance Testing **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3507) in GitLab 10.3.
+
+If your application offers a web interface and you're using
+[GitLab CI/CD](../index.md), you can quickly determine the rendering performance
+impact of pending code changes in the browser.
+
+NOTE:
+You can automate this feature in your applications by using [Auto DevOps](../../topics/autodevops/index.md).
+
+## Overview
+
+GitLab uses [Sitespeed.io](https://www.sitespeed.io), a free and open source
+tool, for measuring the rendering performance of web sites. The
+[Sitespeed plugin](https://gitlab.com/gitlab-org/gl-performance) that GitLab built outputs
+the performance score for each page analyzed in a file called `browser-performance.json`
+this data can be shown on Merge Requests.
+
+## Use cases
+
+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 the new JavaScript library was
+   included in `<head>`, which affects loading page speed.
+1. They ask for help from a front end developer, who sets the library to load asynchronously.
+1. The frontend developer approves the merge request, and authorizes its deployment to production.
+
+## How browser performance testing works
+
+First, define a job in your `.gitlab-ci.yml` file that generates the
+[Browser Performance report artifact](../yaml/artifacts_reports.md#artifactsreportsbrowser_performance).
+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.
+
+For an example Browser Performance job, see
+[Configuring Browser Performance Testing](#configuring-browser-performance-testing).
+
+NOTE:
+If the Browser Performance report has no data to compare, such as when you add the
+Browser Performance job in your `.gitlab-ci.yml` for the very first time,
+the Browser Performance report widget doesn't display. It must have run at least
+once on the target branch (`main`, for example), before it displays in a
+merge request targeting that branch.
+
+![Browser Performance Widget](img/browser_performance_testing.png)
+
+## Configuring Browser Performance Testing
+
+This example shows how to run the [sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/)
+on your code by using GitLab CI/CD and [sitespeed.io](https://www.sitespeed.io)
+using Docker-in-Docker.
+
+1. First, set up GitLab Runner with a
+   [Docker-in-Docker build](../docker/using_docker_build.md#use-docker-in-docker).
+1. Configure the default Browser Performance Testing CI/CD job as follows in your `.gitlab-ci.yml` file:
+
+   ```yaml
+   include:
+     template: Verify/Browser-Performance.gitlab-ci.yml
+
+   browser_performance:
+     variables:
+       URL: https://example.com
+   ```
+
+WARNING:
+In GitLab 13.12 and earlier, the job [was named](https://gitlab.com/gitlab-org/gitlab/-/issues/225914) `performance`.
+
+The above example:
+
+- Creates a `browser_performance` job in your CI/CD pipeline and runs sitespeed.io against the webpage you
+  defined in `URL` to gather key metrics.
+- Uses a template that doesn't work with Kubernetes clusters. If you are using a Kubernetes cluster,
+  use [`template: Jobs/Browser-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Browser-Performance-Testing.gitlab-ci.yml)
+   instead.
+- Uses a CI/CD template that is included in all GitLab installations since 12.4. If you are using
+  GitLab 12.3 or earlier, you must [add the configuration manually](#gitlab-versions-132-and-earlier).
+
+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](../yaml/artifacts_reports.md#artifactsreportsbrowser_performance)
+that you can later download and analyze. This implementation always takes the latest
+Browser Performance artifact available. If [GitLab Pages](../../user/project/pages/index.md) is enabled,
+you can view the report directly in your browser.
+
+You can also customize the jobs with CI/CD 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 `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
+makes on the given URL, and change the version:
+
+```yaml
+include:
+  template: Verify/Browser-Performance.gitlab-ci.yml
+
+browser_performance:
+  variables:
+    URL: https://www.sitespeed.io/
+    SITESPEED_VERSION: 13.2.0
+    SITESPEED_OPTIONS: -n 5
+```
+
+### Configuring degradation threshold
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27599) in GitLab 13.0.
+
+You can configure the sensitivity of degradation alerts to avoid getting alerts for minor drops in metrics.
+This is done by setting the `DEGRADATION_THRESHOLD` CI/CD variable. In the example below, the alert only shows up
+if the `Total Score` metric degrades by 5 points or more:
+
+```yaml
+include:
+  template: Verify/Browser-Performance.gitlab-ci.yml
+
+browser_performance:
+  variables:
+    URL: https://example.com
+    DEGRADATION_THRESHOLD: 5
+```
+
+The `Total Score` metric is based on sitespeed.io's [coach performance score](https://www.sitespeed.io/documentation/sitespeed.io/metrics/#performance-score). There is more information in [the coach documentation](https://www.sitespeed.io/documentation/coach/how-to/#what-do-the-coach-do).
+
+### Performance testing on Review Apps
+
+The above CI YAML configuration is great for testing against static environments, and it can
+be extended for dynamic environments, but a few extra steps are required:
+
+1. The `browser_performance` job should run after the dynamic environment has started.
+1. In the `review` job:
+    1. Generate a URL list file with the dynamic URL.
+    1. Save the file as an artifact, for example with `echo $CI_ENVIRONMENT_URL > environment_url.txt`
+    in your job's `script`.
+    1. Pass the list as the URL environment variable (which can be a URL or a file containing URLs)
+    to the `browser_performance` job.
+1. You can now run the sitespeed.io container against the desired hostname and
+   paths.
+
+Your `.gitlab-ci.yml` file would look like:
+
+```yaml
+stages:
+  - deploy
+  - performance
+
+include:
+  template: Verify/Browser-Performance.gitlab-ci.yml
+
+review:
+  stage: deploy
+  environment:
+    name: review/$CI_COMMIT_REF_SLUG
+    url: http://$CI_COMMIT_REF_SLUG.$APPS_DOMAIN
+  script:
+    - run_deploy_script
+    - echo $CI_ENVIRONMENT_URL > environment_url.txt
+  artifacts:
+    paths:
+      - environment_url.txt
+  only:
+    - branches
+  except:
+    - master
+
+browser_performance:
+  dependencies:
+    - review
+  variables:
+    URL: environment_url.txt
+```
+
+### GitLab versions 13.2 and earlier
+
+Browser Performance Testing has gone through several changes since its introduction.
+In this section we detail these changes and how you can run the test based on your
+GitLab version:
+
+- In 13.2 the feature was renamed from `Performance` to `Browser Performance` with additional
+  template CI/CD variables.
+- In GitLab 12.4 [a job template was made available](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml).
+- For 11.5 to 12.3 no template is available and the job has to be defined manually as follows:
+
+  ```yaml
+  performance:
+    stage: performance
+    image: docker:git
+    variables:
+      URL: https://example.com
+      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/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
+    artifacts:
+      paths:
+        - performance.json
+        - sitespeed-results/
+      reports:
+        performance: performance.json
+  ```
+
+- For 11.4 and earlier the job should be defined as follows:
+
+  ```yaml
+  performance:
+    stage: performance
+    image: docker:git
+    variables:
+      URL: https://example.com
+    services:
+      - docker:stable-dind
+    script:
+      - mkdir gitlab-exporter
+      - 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
+    artifacts:
+      paths:
+        - performance.json
+        - sitespeed-results/
+  ```
+
+Upgrading to the latest version and using the templates is recommended, to ensure
+you receive the latest updates, including updates to the sitespeed.io versions.
diff --git a/doc/ci/testing/code_quality.md b/doc/ci/testing/code_quality.md
new file mode 100644
index 00000000000..401279b9601
--- /dev/null
+++ b/doc/ci/testing/code_quality.md
@@ -0,0 +1,636 @@
+---
+stage: Secure
+group: Static Analysis
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Code Quality **(FREE)**
+
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) to GitLab Free in 13.2.
+
+To ensure your project's code stays simple, readable, and easy to contribute to,
+you can use [GitLab CI/CD](../index.md) to analyze your source code quality.
+
+For example, while you're implementing a feature, you can run Code Quality reports
+to analyze how your improvements are impacting your code's quality. You can
+use this information to ensure that your changes are improving performance rather
+than degrading it.
+
+Code Quality:
+
+- Uses [plugins](https://docs.codeclimate.com/docs/list-of-engines) supported by Code Climate, which are
+  free and open source. Code Quality does not require a Code Climate
+  subscription.
+- Runs in [pipelines](../pipelines/index.md) by using a Docker image built in the
+  [GitLab Code Quality](https://gitlab.com/gitlab-org/ci-cd/codequality) project.
+- Uses [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 by using [Auto Code Quality](../../topics/autodevops/stages.md#auto-code-quality), provided by [Auto DevOps](../../topics/autodevops/index.md).
+- Can be extended through [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) or a [custom tool](#implementing-a-custom-tool).
+
+## Summary of features per tier
+
+Different features are available in different [GitLab tiers](https://about.gitlab.com/pricing/),
+as shown in the following table:
+
+| Capability                                                            | In Free             | In Premium          | In Ultimate        |
+|:----------------------------------------------------------------------|:--------------------|:--------------------|:-------------------|
+| [Configure scanners](#configuring-jobs-using-variables)               | **{check-circle}**  | **{check-circle}**  | **{check-circle}** |
+| [Integrate custom scanners](#implementing-a-custom-tool)              | **{check-circle}**  | **{check-circle}**  | **{check-circle}** |
+| [Generate JSON or HTML report artifacts](#generate-an-html-report)    | **{check-circle}**  | **{check-circle}**  | **{check-circle}** |
+| [See findings in merge request widget](#code-quality-widget)          | **{check-circle}**  | **{check-circle}**  | **{check-circle}** |
+| [See reports in CI pipelines](#code-quality-reports)                  | **{dotted-circle}** | **{check-circle}**  | **{check-circle}** |
+| [See findings in merge request diff view](#code-quality-in-diff-view) | **{dotted-circle}** | **{dotted-circle}** | **{check-circle}** |
+
+## Code Quality Widget
+
+> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) to GitLab Free in 13.2.
+
+Going a step further, GitLab can show the Code Quality report right
+in the merge request widget area if a report from the target branch is available to compare to:
+
+![Code Quality Widget](img/code_quality_widget_13_11.png)
+
+Watch a quick walkthrough of Code Quality in action:
+
+<div class="video-fallback">
+  See the video: <a href="https://www.youtube.com/watch?v=B32LxtJKo9M">Code Quality: Speed Run</a>.
+</div>
+<figure class="video-container">
+  <iframe src="https://www.youtube.com/embed/B32LxtJKo9M" frameborder="0" allowfullscreen="true"> </iframe>
+</figure>
+
+NOTE:
+For one customer, the auditor found that having Code Quality, SAST, and Container Scanning all automated in GitLab CI/CD was almost better than a manual review! [Read more](https://about.gitlab.com/customers/bi_worldwide/).
+
+See also the Code Climate list of [Supported Languages for Maintainability](https://docs.codeclimate.com/docs/supported-languages-for-maintainability).
+
+## Code Quality in diff view **(ULTIMATE)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/267612) in GitLab 13.11, disabled by default behind the `codequality_mr_diff` [feature flag](../../administration/feature_flags.md).
+> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/284140) in GitLab 13.12.
+> - [Disabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/2526) in GitLab 14.0 due to [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/334116).
+> - [Inline annotation added](https://gitlab.com/gitlab-org/gitlab/-/issues/2526) and [feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/284140) in GitLab 14.1.
+
+Changes to files in merge requests can cause Code Quality to fall if merged. In these cases,
+the merge request's diff view displays an indicator next to lines with new Code Quality violations. For example:
+
+![Code Quality MR diff report](img/code_quality_mr_diff_report_v14_2.png)
+
+## Example configuration
+
+This example shows how to run Code Quality on your code by using GitLab CI/CD and Docker.
+
+- Using shared runners, the job should be configured For the [Docker-in-Docker workflow](../docker/using_docker_build.md#use-docker-in-docker).
+- Using private runners, there is an [alternative configuration](#set-up-a-private-runner-for-code-quality-without-docker-in-docker) recommended for running Code Quality analysis more efficiently.
+
+In either configuration, the runner must have 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 GitLab Runner, include the [Code Quality template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Code-Quality.gitlab-ci.yml) in your CI configuration:
+
+```yaml
+include:
+  - template: Code-Quality.gitlab-ci.yml
+```
+
+The above example creates a `code_quality` job in your CI/CD pipeline which
+scans your source code for code quality issues. The report is saved as a
+[Code Quality report artifact](../yaml/artifacts_reports.md#artifactsreportscodequality)
+that you can later download and analyze.
+
+It's also possible to override the URL to the Code Quality image by
+setting the `CODE_QUALITY_IMAGE` CI/CD variable. This is particularly useful if you want
+to lock in a specific version of Code Quality, or use a fork of it:
+
+```yaml
+include:
+  - template: Code-Quality.gitlab-ci.yml
+
+code_quality:
+  variables:
+    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:
+
+```yaml
+include:
+  - template: Code-Quality.gitlab-ci.yml
+
+code_quality:
+  artifacts:
+    paths: [gl-code-quality-report.json]
+```
+
+The included `code_quality` job is running in the `test` stage, so it needs to be included in your CI configuration, like so:
+
+```yaml
+stages:
+  - test
+```
+
+NOTE:
+This information is automatically extracted and shown right in the merge request widget.
+
+WARNING:
+On self-managed instances, if a malicious actor compromises the Code Quality job
+definition they could execute privileged Docker commands on the runner
+host. Having proper access control policies mitigates this attack vector by
+allowing access only to trusted actors.
+
+### Set up a private runner for code quality without Docker-in-Docker
+
+It's possible to configure your own runners and avoid Docker-in-Docker. You can use a
+configuration that may greatly speed up job execution without requiring your runners
+to operate in privileged mode.
+
+This alternative configuration uses socket binding to share the Runner's Docker daemon
+with the job environment. Be aware that this configuration [has significant considerations](../docker/using_docker_build.md#use-docker-socket-binding)
+to be consider, but may be preferable depending on your use case.
+
+1. Register a new runner:
+
+   ```shell
+   $ gitlab-runner register --executor "docker" \
+     --docker-image="docker:stable" \
+     --url "https://gitlab.com/" \
+     --description "cq-sans-dind" \
+     --tag-list "cq-sans-dind" \
+     --locked="false" \
+     --access-level="not_protected" \
+     --docker-volumes "/cache"\
+     --docker-volumes "/builds:/builds"\
+     --docker-volumes "/var/run/docker.sock:/var/run/docker.sock" \
+     --registration-token="<project_token>" \
+     --non-interactive
+   ```
+
+1. **Optional, but recommended:** Set the builds directory to `/tmp/builds`,
+  so job artifacts are periodically purged from the runner host. If you skip
+  this step, you must clean up the default builds directory (`/builds`) yourself.
+  You can do this by adding the following two flags to `gitlab-runner register`
+  in the previous step.
+
+   ```shell
+   --builds-dir "/tmp/builds"
+   --docker-volumes "/tmp/builds:/tmp/builds" # Use this instead of --docker-volumes "/builds:/builds"
+   ```
+
+   The resulting configuration:
+
+   ```toml
+   [[runners]]
+     name = "cq-sans-dind"
+     url = "https://gitlab.com/"
+     token = "<project_token>"
+     executor = "docker"
+     builds_dir = "/tmp/builds"
+     [runners.docker]
+       tls_verify = false
+       image = "docker:stable"
+       privileged = false
+       disable_entrypoint_overwrite = false
+       oom_kill_disable = false
+       disable_cache = false
+       volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock", "/tmp/builds:/tmp/builds"]
+       shm_size = 0
+     [runners.cache]
+       [runners.cache.s3]
+       [runners.cache.gcs]
+   ```
+
+1. Apply two overrides to the `code_quality` job created by the template:
+
+   ```yaml
+   include:
+     - template: Code-Quality.gitlab-ci.yml
+
+   code_quality:
+     services:            # Shut off Docker-in-Docker
+     tags:
+       - cq-sans-dind     # Set this job to only run on our new specialized runner
+   ```
+
+The end result is that:
+
+- Privileged mode is not used.
+- Docker-in-Docker is not used.
+- Docker images, including all CodeClimate images, are cached, and not re-fetched for subsequent jobs.
+
+With this configuration, the run time for a second pipeline is much shorter. For example
+this [small change](https://gitlab.com/drew/test-code-quality-template/-/merge_requests/4/diffs?commit_id=1e705607aef7236c1b20bb6f637965f3f3e53a46)
+to an [open merge request](https://gitlab.com/drew/test-code-quality-template/-/merge_requests/4/pipelines)
+running Code Quality analysis ran significantly faster the second time:
+
+![Code Quality sequential runs without DinD](img/code_quality_host_bound_sequential.png)
+
+This configuration is not possible on `gitlab.com` shared runners. Shared runners
+are configured with `privileged=true`, and they do not expose `docker.sock` into
+the job container. As a result, socket binding cannot be used to make `docker` available
+in the context of the job script.
+
+[Docker-in-Docker](../docker/using_docker_build.md#use-docker-in-docker)
+was chosen as an operational decision by the runner team, instead of exposing `docker.sock`.
+
+### Disabling the code quality job
+
+The `code_quality` job doesn't run if the `$CODE_QUALITY_DISABLED` CI/CD variable
+is present. Please refer to the CI/CD variables [documentation](../variables/index.md)
+to learn more about how to define one.
+
+To disable the `code_quality` job, add `CODE_QUALITY_DISABLED` as a custom CI/CD variable.
+This can be done:
+
+- For [the whole project](../variables/index.md#custom-cicd-variables).
+- For a single pipeline run:
+
+  1. Go to **CI/CD > Pipelines**
+  1. Select **Run pipeline**
+  1. Add `CODE_QUALITY_DISABLED` as the variable key, with any value.
+
+### Using with merge request pipelines
+
+The configuration provided by the Code Quality template does not let the `code_quality` job
+run on [merge request pipelines](../pipelines/merge_request_pipelines.md).
+
+If merge request pipelines is enabled, the `code_quality:rules` must be redefined.
+
+The template has these [`rules`](../yaml/index.md#rules) for the `code quality` job:
+
+```yaml
+code_quality:
+  rules:
+    - if: $CODE_QUALITY_DISABLED
+      when: never
+    - if: $CI_COMMIT_TAG || $CI_COMMIT_BRANCH
+```
+
+If you are using merge request pipelines, your `rules` (or [`workflow: rules`](../yaml/index.md#workflow))
+might look like this example:
+
+```yaml
+job1:
+  rules:
+    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # Run job1 in merge request pipelines
+    - if: $CI_COMMIT_BRANCH == "main"                  # Run job1 in pipelines on the main branch (but not in other branch pipelines)
+    - if: $CI_COMMIT_TAG                               # Run job1 in pipelines for tags
+```
+
+To make these work together, you need to overwrite the code quality `rules`
+so that they match your current `rules`. From the example above, it could look like:
+
+```yaml
+include:
+  - template: Code-Quality.gitlab-ci.yml
+
+code_quality:
+  rules:
+    - if: $CODE_QUALITY_DISABLED
+      when: never
+    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # Run code quality job in merge request pipelines
+    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH      # Run code quality job in pipelines on the default branch (but not in other branch pipelines)
+    - if: $CI_COMMIT_TAG                               # Run code quality job in pipelines for tags
+```
+
+### Configure Code Quality to use a private container image registry
+
+> [Introduced](https://gitlab.com/gitlab-org/ci-cd/codequality/-/merge_requests/30) in 13.7.
+
+To reduce network time and external dependency, you can use your own
+container image registry to host the Code Quality Docker images. Because of
+the nested architecture of container execution, the registry prefix must
+be specifically configured to be passed down into CodeClimate's subsequent
+`docker pull` commands for individual engines.
+
+The following two variables can address all of the required image pulls:
+
+- `CODE_QUALITY_IMAGE`: A fully prefixed image name that can be located anywhere
+  accessible from your job environment. GitLab Container Registry can be used here
+  to host your own copy.
+- `CODECLIMATE_PREFIX`: The domain of your intended container image registry. This
+  is a configuration option supported by [CodeClimate CLI](https://github.com/codeclimate/codeclimate/pull/948). You must:
+  - Include a trailing slash (`/`).
+  - Not include a protocol prefix, such as `https://`.
+
+```yaml
+include:
+  - template: Jobs/Code-Quality.gitlab-ci.yml
+
+code_quality:
+  variables:
+    CODE_QUALITY_IMAGE: "my-private-registry.local:12345/codequality:0.85.24"
+    CODECLIMATE_PREFIX: "my-private-registry.local:12345/"
+```
+
+The images in the private container image registry must be available without authentication.
+Follow [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/355814) for more information.
+
+This example is specific to GitLab Code Quality. For more general
+instructions on how to configure DinD with a registry mirror, see the
+relevant [documentation](../docker/using_docker_build.md#enable-registry-mirror-for-dockerdind-service).
+
+## Configuring jobs using variables
+
+The Code Quality job supports environment variables that users can set to
+configure job execution at runtime.
+
+For a list of available environment variables, see
+[Environment variables](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables).
+
+## Implementing a custom tool
+
+It's possible to have a custom tool provide Code Quality reports in GitLab. To
+do this:
+
+1. Define a job in your `.gitlab-ci.yml` file that generates the
+   [Code Quality report artifact](../yaml/artifacts_reports.md#artifactsreportscodequality).
+1. Configure your tool to generate the Code Quality report artifact as a JSON
+   file that implements a subset of the [Code Climate spec](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types).
+
+The Code Quality report artifact JSON file must contain 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.    |
+| `severity`             | A severity string (can be `info`, `minor`, `major`, `critical`, or `blocker`).            |
+| `location.path`        | The relative path to the file containing the code quality violation.                      |
+| `location.lines.begin` or `location.positions.begin.line` | The line on which the code quality violation occurred. |
+
+Example:
+
+```json
+[
+  {
+    "description": "'unused' is assigned a value but never used.",
+    "fingerprint": "7815696ecbf1c96e6894b779456d330e",
+    "severity": "minor",
+    "location": {
+      "path": "lib/index.js",
+      "lines": {
+        "begin": 42
+      }
+    }
+  }
+]
+```
+
+NOTE:
+Although the Code Climate spec supports more properties, those are ignored by
+GitLab.
+The GitLab parser does not allow a [byte order mark](https://en.wikipedia.org/wiki/Byte_order_mark)
+at the beginning of the file.
+
+## Code Quality reports **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21527) in GitLab 12.9.
+
+![Code Quality Report](img/code_quality_report_13_11.png)
+
+After the Code Quality job completes:
+
+- Potential changes to code quality are shown directly in the merge request.
+  The Code Quality widget in the merge request compares the reports from the base and head of the branch,
+  then lists any violations that are resolved or created when the branch is merged.
+- The full JSON report is available as a
+  [downloadable artifact](../pipelines/job_artifacts.md#download-job-artifacts)
+  for the `code_quality` job.
+- The full list of code quality violations generated by a pipeline is shown in the
+  Code Quality tab of the Pipeline Details page.
+
+## Generate an HTML report
+
+In [GitLab 13.6 and later](https://gitlab.com/gitlab-org/ci-cd/codequality/-/issues/10),
+it is possible to generate an HTML report file by setting the `REPORT_FORMAT`
+CI/CD variable to `html`. This is useful if you just want to view the report in a more
+human-readable format or to publish this artifact on GitLab Pages for even
+easier reviewing.
+
+To generate both JSON and HTML report files, add another job to your template by using `extends: code_quality`:
+
+```yaml
+include:
+  - template: Code-Quality.gitlab-ci.yml
+
+code_quality_html:
+  extends: code_quality
+  variables:
+    REPORT_FORMAT: html
+  artifacts:
+    paths: [gl-code-quality-report.html]
+```
+
+NOTE:
+Adding a job means your code is scanned twice: once to generate a JSON report and once to generate an HTML report.
+
+You can also generate _only_ an HTML report instead of the standard JSON report. To do so, set `REPORT_FORMAT` to `html` in the existing job:
+
+```yaml
+include:
+  - template: Code-Quality.gitlab-ci.yml
+
+code_quality:
+  variables:
+    REPORT_FORMAT: html
+  artifacts:
+    paths: [gl-code-quality-report.html]
+```
+
+WARNING:
+If you only generate an HTML report, you can't see your results in the [merge request widget](#code-quality-widget), [pipeline report](#code-quality-reports), or [diff view](#code-quality-in-diff-view).
+These features require a JSON report.
+
+## Extending functionality
+
+### Using Analysis Plugins
+
+Should there be a need to extend the default functionality provided by Code Quality, as stated in [Code Quality](#code-quality), [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) are available.
+
+For example, to use the [SonarJava analyzer](https://docs.codeclimate.com/docs/sonar-java),
+add a file named `.codeclimate.yml` containing the [enablement code](https://docs.codeclimate.com/docs/sonar-java#enable-the-plugin)
+for the plugin to the root of your repository:
+
+```yaml
+version: "2"
+plugins:
+  sonar-java:
+    enabled: true
+```
+
+This adds SonarJava to the `plugins:` section of the [default `.codeclimate.yml`](https://gitlab.com/gitlab-org/ci-cd/codequality/-/blob/master/codeclimate_defaults/.codeclimate.yml.template)
+included in your project.
+
+Changes to the `plugins:` section do not affect the `exclude_patterns` section of the
+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.
+
+Here's [an example project](https://gitlab.com/jheimbuck_gl/jh_java_example_project) that uses Code Quality with a `.codeclimate.yml` file.
+
+## Use a Code Quality image hosted in a registry with untrusted certificates
+
+If you set the `CODE_QUALITY_IMAGE` to an image that is hosted in a
+Docker registry which uses a TLS certificate that is not trusted, such as
+a self-signed certificate, you can see errors like the one below:
+
+```shell
+$ docker pull --quiet "$CODE_QUALITY_IMAGE"
+Error response from daemon: Get https://gitlab.example.com/v2/: x509: certificate signed by unknown authority
+```
+
+To fix this, configure the Docker daemon to [trust certificates](https://docs.docker.com/registry/insecure/#use-self-signed-certificates)
+by putting the certificate inside of the `/etc/docker/certs.d`
+directory.
+
+This Docker daemon is exposed to the subsequent Code Quality Docker container in the
+[GitLab Code Quality template](https://gitlab.com/gitlab-org/gitlab/-/blob/v13.8.3-ee/lib/gitlab/ci/templates/Jobs/Code-Quality.gitlab-ci.yml#L41)
+and should be to exposed any other containers in which you want to have
+your certificate configuration apply.
+
+### Docker
+
+If you have access to GitLab Runner configuration, add the directory as a
+[volume mount](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#volumes-in-the-runnersdocker-section). For example:
+
+```toml
+[[runners]]
+  ...
+  executor = "docker"
+  [runners.docker]
+    ...
+    privileged = true
+    volumes = ["/cache", "/etc/gitlab-runner/certs/gitlab.example.com.crt:/etc/docker/certs.d/gitlab.example.com/ca.crt:ro"]
+```
+
+Replace `gitlab.example.com` with the actual domain of the registry.
+
+### Kubernetes
+
+If you have access to GitLab Runner configuration and the Kubernetes cluster,
+you can [mount a ConfigMap](https://docs.gitlab.com/runner/executors/kubernetes.html#configmap-volumes):
+
+1. Create a ConfigMap with the certificate:
+
+   ```shell
+   kubectl create configmap registry-crt --namespace gitlab-runner --from-file /etc/gitlab-runner/certs/gitlab.example.com.crt
+   ```
+
+1. Update GitLab Runner `config.toml` to specify the ConfigMap:
+
+   ```toml
+   [[runners]]
+     ...
+     executor = "kubernetes"
+     [runners.kubernetes]
+       image = "alpine:3.12"
+       privileged = true
+       [[runners.kubernetes.volumes.config_map]]
+         name = "registry-crt"
+         mount_path = "/etc/docker/certs.d/gitlab.example.com/ca.crt"
+         sub_path = "gitlab.example.com.crt"
+   ```
+
+Replace `gitlab.example.com` with the actual domain of the registry.
+
+## Troubleshooting
+
+### Changing the default configuration has no effect
+
+A common issue is that the terms `Code Quality` (GitLab specific) and `Code Climate`
+(Engine used by GitLab) are very similar. You must add a **`.codeclimate.yml`** file
+to change the default configuration, **not** a `.codequality.yml` file. If you use
+the wrong filename, the [default `.codeclimate.yml`](https://gitlab.com/gitlab-org/ci-cd/codequality/-/blob/master/codeclimate_defaults/.codeclimate.yml.template)
+is still used.
+
+### No Code Quality report is displayed in a merge request
+
+This can be due to multiple reasons:
+
+- You just added the Code Quality job in your `.gitlab-ci.yml`. The report does not
+  have anything to compare to yet, so no information can be displayed. It only displays
+  after future merge requests have something to compare to.
+- Your pipeline is not set to run the code quality job on your target branch. If there is no report generated from the target branch, your MR branch reports have nothing to compare to. In this situation you will see an error stating `Base pipeline codequality artifact not found`.
+- If no [degradation or error is detected](https://docs.codeclimate.com/docs/maintainability#section-checks),
+  nothing is displayed.
+- The [`artifacts:expire_in`](../yaml/index.md#artifactsexpire_in) CI/CD
+  setting can cause the Code Quality artifacts to expire faster than desired.
+- The widgets use the pipeline of the latest commit to the target branch. If commits are made to the default branch that do not run the code quality job, this may cause the merge request widget to have no base report for comparison.
+- If you use the [`REPORT_STDOUT` environment variable](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables), no report file is generated and nothing displays in the merge request.
+- Large `gl-code-quality-report.json` files (esp. >10 MB) are [known to prevent the report from being displayed](https://gitlab.com/gitlab-org/gitlab/-/issues/2737).
+  As a work-around, try removing [properties](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types)
+  that are [ignored by GitLab](#implementing-a-custom-tool). You can:
+  - Configure the Code Quality tool to not output those types.
+  - Use `sed`, `awk` or similar commands in the `.gitlab-ci.yml` script to
+    edit the `gl-code-quality-report.json` before the job completes.
+
+### Only a single Code Quality report is displayed, but more are defined
+
+GitLab only uses the Code Quality artifact from the latest created job (with the largest job ID).
+If multiple jobs in a pipeline generate a code quality artifact, those of earlier jobs are ignored.
+To avoid confusion, configure only one job to generate a `gl-code-quality-report.json`.
+
+### RuboCop errors
+
+When using Code Quality jobs on a Ruby project, you can encounter problems running RuboCop.
+For example, the following error can appear when using either a very recent or very old version
+of Ruby:
+
+```plaintext
+/usr/local/bundle/gems/rubocop-0.52.1/lib/rubocop/config.rb:510:in `check_target_ruby':
+Unknown Ruby version 2.7 found in `.ruby-version`. (RuboCop::ValidationError)
+Supported versions: 2.1, 2.2, 2.3, 2.4, 2.5
+```
+
+This is caused by the default version of RuboCop used by the check engine not covering
+support for the Ruby version in use.
+
+To use a custom version of RuboCop that
+[supports the version of Ruby used by the project](https://docs.rubocop.org/rubocop/compatibility.html#support-matrix),
+you can [override the configuration through a `.codeclimate.yml` file](https://docs.codeclimate.com/docs/rubocop#using-rubocops-newer-versions)
+created in the project repository.
+
+For example, to specify using RuboCop release **0.67**:
+
+```yaml
+version: "2"
+plugins:
+  rubocop:
+    enabled: true
+    channel: rubocop-0-67
+```
+
+### No Code Quality appears on merge requests when using custom tool
+
+If your merge requests do not show any code quality changes when using a custom tool,
+ensure that the line property is an `integer`.
+
+### Code Quality CI job with Code Climate plugins enabled fails with error
+
+If you enabled any of the Code Climate plugins, and the Code Quality CI job fails with the error
+below, it's likely the job takes longer than the default timeout of 900 seconds:
+
+```shell
+error: (CC::CLI::Analyze::EngineFailure) engine pmd ran for 900 seconds and was killed
+Could not analyze code quality for the repository at /code
+```
+
+To work around this problem, set `TIMEOUT_SECONDS` to a higher value in your `.gitlab.-ci.yml` file.
+
+For example:
+
+```yaml
+variables:
+  TIMEOUT_SECONDS: 3600
+```
diff --git a/doc/ci/testing/fail_fast_testing.md b/doc/ci/testing/fail_fast_testing.md
new file mode 100644
index 00000000000..7b95b1ac54a
--- /dev/null
+++ b/doc/ci/testing/fail_fast_testing.md
@@ -0,0 +1,97 @@
+---
+stage: Verify
+group: Pipeline Insights
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Fail Fast Testing **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/198550) in GitLab 13.1.
+
+For applications that use RSpec for running tests, we've introduced the `Verify/Failfast`
+[template to run subsets of your test suite](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Verify/FailFast.gitlab-ci.yml),
+based on the changes in your merge request.
+
+The template uses the [test_file_finder (`tff`) gem](https://gitlab.com/gitlab-org/ci-cd/test_file_finder/)
+that accepts a list of files as input, and returns a list of spec (test) files
+that it believes to be relevant to the input files.
+
+`tff` is designed for Ruby on Rails projects, so the `Verify/FailFast` template is
+configured to run when changes to Ruby files are detected. By default, it runs in
+the [`.pre` stage](../yaml/index.md#stage-pre) of a GitLab CI/CD pipeline,
+before all other stages.
+
+## Example use case
+
+Fail fast testing is useful when adding new functionality to a project and adding
+new automated tests.
+
+Your project could have hundreds of thousands of tests that take a long time to complete.
+You may be confident that a new test will pass, but you have to wait for all the tests
+to complete to verify it. This could take an hour or more, even when using parallelization.
+
+Fail fast testing gives you a faster feedback loop from the pipeline. It lets you
+know quickly that the new tests are passing and the new functionality did not break
+other tests.
+
+## Requirements
+
+This template requires:
+
+- A project built in Rails that uses RSpec for testing.
+- CI/CD configured to:
+  - Use a Docker image with Ruby available.
+  - Use [Merge request pipelines](../pipelines/merge_request_pipelines.md#prerequisites)
+- [Merged results pipelines](../pipelines/merged_results_pipelines.md#enable-merged-results-pipelines)
+  enabled in the project settings.
+- A Docker image with Ruby available. The template uses `image: ruby:2.6` by default, but you [can override](../yaml/includes.md#override-included-configuration-values) this.
+
+## Configuring Fast RSpec Failure
+
+We use the following plain RSpec configuration as a starting point. It installs all the
+project gems and executes `rspec`, on merge request pipelines only.
+
+```yaml
+rspec-complete:
+  stage: test
+  rules:
+    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
+  script:
+    - bundle install
+    - bundle exec rspec
+```
+
+To run the most relevant specs first instead of the whole suite, [`include`](../yaml/index.md#include)
+the template by adding the following to your CI/CD configuration:
+
+```yaml
+include:
+  - template: Verify/FailFast.gitlab-ci.yml
+```
+
+To customize the job, specific options may be set to override the template. For example, to override the default Docker image:
+
+```yaml
+include:
+  - template: Verify/FailFast.gitlab-ci.yml
+
+rspec-rails-modified-path-specs:
+  image: custom-docker-image-with-ruby
+```
+
+### Example test loads
+
+For illustrative purposes, let's say our Rails app spec suite consists of 100 specs per model for ten models.
+
+If no Ruby files are changed:
+
+- `rspec-rails-modified-paths-specs` does not run any tests.
+- `rspec-complete` runs the full suite of 1000 tests.
+
+If one Ruby model is changed, for example `app/models/example.rb`, then `rspec-rails-modified-paths-specs`
+runs the 100 tests for `example.rb`:
+
+- If all of these 100 tests pass, then the full `rspec-complete` suite of 1000 tests is allowed to run.
+- If any of these 100 tests fail, they fail quickly, and `rspec-complete` does not run any tests.
+
+The final case saves resources and time as the full 1000 test suite does not run.
diff --git a/doc/ci/testing/img/accessibility_mr_widget_v13_0.png b/doc/ci/testing/img/accessibility_mr_widget_v13_0.png
new file mode 100644
index 00000000000..4ada7e25b65
--- /dev/null
+++ b/doc/ci/testing/img/accessibility_mr_widget_v13_0.png
diff --git a/doc/ci/testing/img/browser_performance_testing.png b/doc/ci/testing/img/browser_performance_testing.png
new file mode 100644
index 00000000000..a3d7022bcfc
--- /dev/null
+++ b/doc/ci/testing/img/browser_performance_testing.png
diff --git a/doc/ci/testing/img/code_quality_host_bound_sequential.png b/doc/ci/testing/img/code_quality_host_bound_sequential.png
new file mode 100644
index 00000000000..2b31f3b42ee
--- /dev/null
+++ b/doc/ci/testing/img/code_quality_host_bound_sequential.png
diff --git a/doc/ci/testing/img/code_quality_mr_diff_report_v14_2.png b/doc/ci/testing/img/code_quality_mr_diff_report_v14_2.png
new file mode 100644
index 00000000000..c1e9aad24ac
--- /dev/null
+++ b/doc/ci/testing/img/code_quality_mr_diff_report_v14_2.png
diff --git a/doc/ci/testing/img/code_quality_report_13_11.png b/doc/ci/testing/img/code_quality_report_13_11.png
new file mode 100644
index 00000000000..36341548328
--- /dev/null
+++ b/doc/ci/testing/img/code_quality_report_13_11.png
diff --git a/doc/ci/testing/img/code_quality_widget_13_11.png b/doc/ci/testing/img/code_quality_widget_13_11.png
new file mode 100644
index 00000000000..57978a0ed96
--- /dev/null
+++ b/doc/ci/testing/img/code_quality_widget_13_11.png
diff --git a/doc/ci/testing/img/load_performance_testing.png b/doc/ci/testing/img/load_performance_testing.png
new file mode 100644
index 00000000000..d5623867ee7
--- /dev/null
+++ b/doc/ci/testing/img/load_performance_testing.png
diff --git a/doc/ci/img/metrics_reports_advanced_v13_0.png b/doc/ci/testing/img/metrics_reports_advanced_v13_0.png
index e96fdcf620a..e96fdcf620a 100644
--- a/doc/ci/img/metrics_reports_advanced_v13_0.png
+++ b/doc/ci/testing/img/metrics_reports_advanced_v13_0.png
diff --git a/doc/ci/img/metrics_reports_v13_0.png b/doc/ci/testing/img/metrics_reports_v13_0.png
index 1597031db0b..1597031db0b 100644
--- a/doc/ci/img/metrics_reports_v13_0.png
+++ b/doc/ci/testing/img/metrics_reports_v13_0.png
diff --git a/doc/ci/testing/img/test_coverage_visualization_v12_9.png b/doc/ci/testing/img/test_coverage_visualization_v12_9.png
new file mode 100644
index 00000000000..1922a566dd5
--- /dev/null
+++ b/doc/ci/testing/img/test_coverage_visualization_v12_9.png
diff --git a/doc/ci/testing/img/unit_test_report_screenshot_v13_12.png b/doc/ci/testing/img/unit_test_report_screenshot_v13_12.png
new file mode 100644
index 00000000000..d5b1775b4ca
--- /dev/null
+++ b/doc/ci/testing/img/unit_test_report_screenshot_v13_12.png
diff --git a/doc/ci/testing/index.md b/doc/ci/testing/index.md
index 52af329873f..a8f06ec695c 100644
--- a/doc/ci/testing/index.md
+++ b/doc/ci/testing/index.md
@@ -9,18 +9,18 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Use GitLab CI/CD to test the changes included in a feature branch. You can also
 display reports or link to important information directly from [merge requests](../../user/project/merge_requests/index.md).
 
-| Feature                                                                                         | Description |
-|-------------------------------------------------------------------------------------------------|-------------|
-| [Accessibility Testing](../../user/project/merge_requests/accessibility_testing.md)             | Automatically report A11y violations for changed pages in merge requests. |
-| [Browser Performance Testing](../../user/project/merge_requests/browser_performance_testing.md) | Quickly determine the browser performance impact of pending code changes. |
-| [Load Performance Testing](../../user/project/merge_requests/load_performance_testing.md)       | Quickly determine the server performance impact of pending code changes. |
-| [Code Quality](../../user/project/merge_requests/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](../yaml/index.md#artifactsexpose_as)                          | Configure CI pipelines with the `artifacts:expose_as` parameter to directly link to selected [artifacts](../pipelines/job_artifacts.md) in merge requests. |
-| [Unit test reports](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](../../user/compliance/license_compliance/index.md)                         | Manage the licenses of your dependencies. |
-| [Metrics Reports](../metrics_reports.md)                                                        | Display the Metrics Report on the merge request so that it's fast and easier to identify changes to important metrics. |
-| [Test Coverage visualization](../../user/project/merge_requests/test_coverage_visualization.md) | See test coverage results for merge requests, in the file diff. |
-| [Fail fast testing](../../user/project/merge_requests/fail_fast_testing.md#fail-fast-testing)   | Run a subset of your RSpec test suite, so failed tests stop the pipeline before the full suite of tests run, saving resources. |
+| Feature                                                                 | Description |
+|-------------------------------------------------------------------------|-------------|
+| [Accessibility Testing](accessibility_testing.md)                       | Automatically report A11y violations for changed pages in merge requests. |
+| [Browser Performance Testing](browser_performance_testing.md)           | Quickly determine the browser performance impact of pending code changes. |
+| [Load Performance Testing](load_performance_testing.md)                 | Quickly determine the server performance impact of pending code changes. |
+| [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](../yaml/index.md#artifactsexpose_as)  | Configure CI pipelines with the `artifacts:expose_as` parameter to directly link to selected [artifacts](../pipelines/job_artifacts.md) in merge requests. |
+| [Unit test reports](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](../../user/compliance/license_compliance/index.md) | Manage the licenses of your dependencies. |
+| [Metrics Reports](metrics_reports.md)                                   | Display the Metrics Report on the merge request so that it's fast and easier to identify changes to important metrics. |
+| [Test Coverage visualization](test_coverage_visualization.md)           | See test coverage results for merge requests, in the file diff. |
+| [Fail fast testing](fail_fast_testing.md)                               | Run a subset of your RSpec test suite, so failed tests stop the pipeline before the full suite of tests run, saving resources. |
 
 ## Security Reports **(ULTIMATE)**
 
diff --git a/doc/ci/testing/load_performance_testing.md b/doc/ci/testing/load_performance_testing.md
new file mode 100644
index 00000000000..ae177958beb
--- /dev/null
+++ b/doc/ci/testing/load_performance_testing.md
@@ -0,0 +1,201 @@
+---
+stage: Verify
+group: Pipeline Insights
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Load Performance Testing **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10683) in GitLab 13.2.
+
+With Load Performance Testing, you can test the impact of any pending code changes
+to your application's backend in [GitLab CI/CD](../index.md).
+
+GitLab uses [k6](https://k6.io/), a free and open source
+tool, for measuring the system performance of applications under
+load.
+
+Unlike [Browser Performance Testing](browser_performance_testing.md), which is
+used to measure how web sites perform in client browsers, Load Performance Testing
+can be used to perform various types of [load tests](https://k6.io/docs/#use-cases)
+against application endpoints such as APIs, Web Controllers, and so on.
+This can be used to test how the backend or the server performs at scale.
+
+For example, you can use Load Performance Testing to perform many concurrent
+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](../yaml/artifacts_reports.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:
+
+![Load Performance Widget](img/load_performance_testing.png)
+
+Next, you need to configure the test environment and write the k6 test.
+
+The key performance metrics that the merge request widget shows after the test completes are:
+
+- Checks: The percentage pass rate of the [checks](https://k6.io/docs/using-k6/checks) configured in the k6 test.
+- TTFB P90: The 90th percentile of how long it took to start receiving responses, aka the [Time to First Byte](https://en.wikipedia.org/wiki/Time_to_first_byte) (TTFB).
+- TTFB P95: The 95th percentile for TTFB.
+- RPS: The average requests per second (RPS) rate the test was able to achieve.
+
+NOTE:
+If the Load Performance report has no data to compare, such as when you add the
+Load Performance job in your `.gitlab-ci.yml` for the very first time,
+the Load Performance report widget doesn't display. It must have run at least
+once on the target branch (`main`, for example), before it displays in a
+merge request targeting that branch.
+
+## Configure the Load Performance Testing job
+
+Configuring your Load Performance Testing job can be broken down into several distinct parts:
+
+- Determine the test parameters such as throughput, and so on.
+- Set up the target test environment for load performance testing.
+- Design and write the k6 test.
+
+### Determine the test parameters
+
+The first thing you need to do is determine the [type of load test](https://k6.io/docs/test-types/introduction)
+you want to run, and how it will run (for example, the number of users, throughput, and so on).
+
+Refer to the [k6 docs](https://k6.io/docs/), especially the [k6 testing guides](https://k6.io/docs/testing-guides),
+for guidance on the above and more.
+
+### Test Environment setup
+
+A large part of the effort around load performance testing is to prepare the target test environment
+for high loads. You should ensure it's able to handle the
+[throughput](https://k6.io/blog/monthly-visits-concurrent-users) it will be tested with.
+
+It's also typically required to have representative test data in the target environment
+for the load performance test to use.
+
+We strongly recommend [not running these tests against a production environment](https://k6.io/our-beliefs#load-test-in-a-pre-production-environment).
+
+### Write the load performance test
+
+After the environment is prepared, you can write the k6 test itself. k6 is a flexible
+tool and can be used to run [many kinds of performance tests](https://k6.io/docs/test-types/introduction).
+Refer to the [k6 documentation](https://k6.io/docs/) for detailed information on how to write tests.
+
+### Configure the test in GitLab CI/CD
+
+When your k6 test is ready, the next step is to configure the load performance
+testing job in GitLab CI/CD. The easiest way to do this is to use the
+[`Verify/Load-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Load-Performance-Testing.gitlab-ci.yml)
+template that is included with GitLab.
+
+NOTE:
+For large scale k6 tests you need to ensure the GitLab Runner instance performing the actual
+test is able to handle running the test. Refer to [k6's guidance](https://k6.io/docs/testing-guides/running-large-tests#hardware-considerations)
+for spec details. The [default shared GitLab.com runners](../runners/saas/linux_saas_runner.md)
+likely have insufficient specs to handle most large k6 tests.
+
+This template runs the
+[k6 Docker container](https://hub.docker.com/r/loadimpact/k6/) in the job and provides several ways to customize the
+job.
+
+An example configuration workflow:
+
+1. Set up GitLab Runner to run Docker containers, like the
+   [Docker-in-Docker workflow](../docker/using_docker_build.md#use-docker-in-docker).
+1. Configure the default Load Performance Testing CI/CD job in your `.gitlab-ci.yml` file.
+   You need to include the template and configure it with CI/CD variables:
+
+   ```yaml
+   include:
+     template: Verify/Load-Performance-Testing.gitlab-ci.yml
+
+   load_performance:
+     variables:
+       K6_TEST_FILE: <PATH TO K6 TEST FILE IN PROJECT>
+   ```
+
+The above example creates a `load_performance` job in your CI/CD pipeline that runs
+the k6 test.
+
+NOTE:
+For Kubernetes setups a different template should be used: [`Jobs/Load-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Load-Performance-Testing.gitlab-ci.yml).
+
+k6 has [various options](https://k6.io/docs/using-k6/options) to configure how it will run tests, such as what throughput (RPS) to run with,
+how long the test should run, and so on. Almost all options can be configured in the test itself, but as
+you can also pass command line options via the `K6_OPTIONS` variable.
+
+For example, you can override the duration of the test with a CLI option:
+
+```yaml
+  include:
+    template: Verify/Load-Performance-Testing.gitlab-ci.yml
+
+  load_performance:
+    variables:
+      K6_TEST_FILE: <PATH TO K6 TEST FILE IN PROJECT>
+      K6_OPTIONS: '--duration 30s'
+```
+
+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](../yaml/artifacts_reports.md#artifactsreportsload_performance).
+The latest Load Performance artifact available is always used, using the
+summary values from the test.
+
+If [GitLab Pages](../../user/project/pages/index.md) is enabled, you can view the report directly in your browser.
+
+### Load Performance testing in Review Apps
+
+The CI/CD YAML configuration example above works for testing against static environments,
+but it can be extended to work with [review apps](../review_apps/index.md) or
+[dynamic environments](../environments/index.md) with a few extra steps.
+
+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 CI/CD 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, for example, `echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env`.
+   1. Set the `.env` file to be a [job artifact](../pipelines/job_artifacts.md).
+1. In the `load_performance` job:
+   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:
+
+```yaml
+stages:
+  - deploy
+  - performance
+
+include:
+  template: Verify/Load-Performance-Testing.gitlab-ci.yml
+
+review:
+  stage: deploy
+  environment:
+    name: review/$CI_COMMIT_REF_SLUG
+    url: http://$CI_ENVIRONMENT_SLUG.example.com
+  script:
+    - run_deploy_script
+    - echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env
+  artifacts:
+    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/ci/testing/metrics_reports.md b/doc/ci/testing/metrics_reports.md
new file mode 100644
index 00000000000..e855074ddea
--- /dev/null
+++ b/doc/ci/testing/metrics_reports.md
@@ -0,0 +1,68 @@
+---
+stage: Verify
+group: Pipeline Insights
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Metrics Reports **(PREMIUM)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9788) in GitLab 11.10. Requires GitLab Runner 11.10 and above.
+
+GitLab provides a lot of great reporting tools for things like [merge requests](../../user/project/merge_requests/index.md) - [Unit test reports](unit_test_reports.md), [code quality](code_quality.md), and performance tests. While JUnit is a great open framework for tests that "pass" or "fail", it is also important to see other types of metrics from a given change.
+
+You can configure your job to use custom Metrics Reports, and GitLab displays a report on the merge request so that it's easier and faster to identify changes without having to check the entire log.
+
+![Metrics Reports](img/metrics_reports_v13_0.png)
+
+## Use cases
+
+Consider the following examples of data that can use Metrics Reports:
+
+1. Memory usage
+1. Load testing results
+1. Code complexity
+1. Code coverage stats
+
+## How it works
+
+Metrics for a branch are read from the latest metrics report artifact (default filename: `metrics.txt`) as string values.
+
+For an MR, the values of these metrics from the feature branch are compared to the values from the target branch. Then they are displayed in the MR widget in this order:
+
+- Existing metrics with changed values.
+- Metrics that have been added by the MR. Marked with a **New** badge.
+- Metrics that have been removed by the MR. Marked with a **Removed** badge.
+- Existing metrics with unchanged values.
+
+## How to set it up
+
+Add a job that creates a [metrics report](../yaml/artifacts_reports.md#artifactsreportsmetrics) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format.
+
+For example:
+
+```yaml
+metrics:
+  script:
+    - echo 'metric_name metric_value' > metrics.txt
+  artifacts:
+    reports:
+      metrics: metrics.txt
+```
+
+## Advanced Example
+
+An advanced example of an OpenMetrics text file (from the [Prometheus documentation](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-format-example))
+renders in the merge request widget as:
+
+![Metrics Reports Advanced](img/metrics_reports_advanced_v13_0.png)
+
+## Troubleshooting
+
+### Metrics reports did not change
+
+You can see `Metrics reports did not change` when trying to view metrics reports in merge requests. Reasons for this are:
+
+- The target branch for the merge request doesn't have a baseline metrics report for comparison.
+- You don't have GitLab license at the Premium tier or above.
+
+There is [an issue open](https://gitlab.com/gitlab-org/gitlab/-/issues/343065) to improve this message.
diff --git a/doc/ci/testing/test_coverage_visualization.md b/doc/ci/testing/test_coverage_visualization.md
new file mode 100644
index 00000000000..472cfca99be
--- /dev/null
+++ b/doc/ci/testing/test_coverage_visualization.md
@@ -0,0 +1,435 @@
+---
+stage: Verify
+group: Pipeline Insights
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Test coverage visualization **(FREE)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3708) in GitLab 12.9.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/249811) in GitLab 13.5.
+
+With the help of [GitLab CI/CD](../index.md), you can collect the test
+coverage information of your favorite testing or coverage-analysis tool, and visualize
+this information inside the file diff view of your merge requests (MRs). This will allow you
+to see which lines are covered by tests, and which lines still require coverage, before the
+MR is merged.
+
+![Test Coverage Visualization Diff View](img/test_coverage_visualization_v12_9.png)
+
+## How test coverage visualization works
+
+Collecting the coverage information is done via GitLab CI/CD's
+[artifacts reports feature](../yaml/index.md#artifactsreports).
+You can specify one or more coverage reports to collect, including wildcard paths.
+GitLab then takes the coverage information in all the files and combines it
+together. Coverage files are parsed in a background job so there can be a delay
+between pipeline completion and the visualization loading on the page.
+
+For the coverage analysis to work, you have to provide a properly formatted
+[Cobertura XML](https://cobertura.github.io/cobertura/) report to
+[`artifacts:reports:coverage_report`](../yaml/artifacts_reports.md#artifactsreportscoverage_report).
+This format was originally developed for Java, but most coverage analysis frameworks
+for other languages have plugins to add support for it, like:
+
+- [simplecov-cobertura](https://rubygems.org/gems/simplecov-cobertura) (Ruby)
+- [gocover-cobertura](https://github.com/boumenot/gocover-cobertura) (Golang)
+
+Other coverage analysis frameworks support the format out of the box, for example:
+
+- [Istanbul](https://istanbul.js.org/docs/advanced/alternative-reporters/#cobertura) (JavaScript)
+- [Coverage.py](https://coverage.readthedocs.io/en/coverage-5.0.4/cmd.html#xml-reporting) (Python)
+- [PHPUnit](https://github.com/sebastianbergmann/phpunit-documentation-english/blob/master/src/textui.rst#command-line-options) (PHP)
+
+Once configured, if you create a merge request that triggers a pipeline which collects
+coverage reports, the coverage is shown in the diff view. This includes reports
+from any job in any stage in the pipeline. The coverage displays for each line:
+
+- `covered` (green): lines which have been checked at least once by tests
+- `no test coverage` (orange): lines which are loaded but never executed
+- no coverage information: lines which are non-instrumented or not loaded
+
+Hovering over the coverage bar provides further information, such as the number
+of times the line was checked by tests.
+
+Uploading a test coverage report does not enable:
+
+- [Test coverage results in merge requests](../pipelines/settings.md#merge-request-test-coverage-results).
+- [Code coverage history](../pipelines/settings.md#view-code-coverage-history).
+
+You must configure these separately.
+
+### Limits
+
+A limit of 100 `<source>` nodes for Cobertura format XML files applies. If your Cobertura report exceeds
+100 nodes, there can be mismatches or no matches in the merge request diff view.
+
+A single Cobertura XML file can be no more than 10MiB. For large projects, split the Cobertura XML into
+smaller files. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328772) for more details.
+When submitting many files, it can take a few minutes for coverage to show on a merge request.
+
+The visualization only displays after the pipeline is complete. If the pipeline has
+a [blocking manual job](../jobs/job_control.md#types-of-manual-jobs), the
+pipeline waits for the manual job before continuing and is not considered complete.
+The visualization cannot be displayed if the blocking manual job did not run.
+
+### Artifact expiration
+
+By default, the [pipeline artifact](../pipelines/pipeline_artifacts.md#storage) used
+to draw the visualization on the merge request expires **one week** after creation.
+
+### Coverage report from child pipeline
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363301) in GitLab 15.1 [with a flag](../../administration/feature_flags.md) named `ci_child_pipeline_coverage_reports`. Disabled by default.
+> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/363557) and feature flag `ci_child_pipeline_coverage_reports` removed in GitLab 15.2.
+
+If a job in a child pipeline creates a coverage report, the report is included in
+the parent pipeline's coverage report.
+
+```yaml
+child_test_pipeline:
+  trigger:
+    include:
+      - local: path/to/child_pipeline_with_coverage.yml
+```
+
+### Automatic class path correction
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217664) in GitLab 13.8.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/284822) in GitLab 13.9.
+
+The coverage report properly matches changed files only if the `filename` of a `class` element
+contains the full path relative to the project root. However, in some coverage analysis frameworks,
+the generated Cobertura XML has the `filename` path relative to the class package directory instead.
+
+To make an intelligent guess on the project root relative `class` path, the Cobertura XML parser
+attempts to build the full path by:
+
+- Extracting a portion of the `source` paths from the `sources` element and combining them with the
+  class `filename` path.
+- Checking if the candidate path exists in the project.
+- Using the first candidate that matches as the class full path.
+
+#### Path correction example
+
+As an example, a project with:
+
+- A full path of `test-org/test-project`.
+- The following files relative to the project root:
+
+  ```shell
+  Auth/User.cs
+  Lib/Utils/User.cs
+  src/main/java
+  ```
+
+In the:
+
+- Cobertura XML, the `filename` attribute in the `class` element assumes the value is a relative
+  path to the project's root:
+
+  ```xml
+  <class name="packet.name" filename="src/main/java" line-rate="0.0" branch-rate="0.0" complexity="5">
+  ```
+
+- `sources` from Cobertura XML, the following paths in the format
+  `<CI_BUILDS_DIR>/<PROJECT_FULL_PATH>/...`:
+
+  ```xml
+  <sources>
+    <source>/builds/test-org/test-project/Auth</source>
+    <source>/builds/test-org/test-project/Lib/Utils</source>
+  </sources>
+  ```
+
+The parser:
+
+- Extracts `Auth` and `Lib/Utils` from the `sources` and uses these to determine the `class` path
+  relative to the project root.
+- Combines these extracted `sources` and the class filename. For example, if there is a `class`
+  element with the `filename` value of `User.cs`, the parser takes the first candidate path that
+  matches, which is `Auth/User.cs`.
+- For each `class` element, attempts to look for a match for each extracted `source` path up to
+  100 iterations. If it reaches this limit without finding a matching path in the file tree, the
+  class is not included in the final coverage report.
+
+NOTE:
+Automatic class path correction only works on `source` paths in the format `<CI_BUILDS_DIR>/<PROJECT_FULL_PATH>/...`.
+The `source` is ignored if the path does not follow this pattern. The parser assumes that the
+`filename` of a `class` element contains the full path relative to the project root.
+
+## Example test coverage configurations
+
+This section provides test coverage configuration examples for different programming languages. You can also see a working example in
+the [`coverage-report`](https://gitlab.com/gitlab-org/ci-sample-projects/coverage-report/) demonstration project.
+
+### JavaScript example
+
+The following [`.gitlab-ci.yml`](../yaml/index.md) example uses [Mocha](https://mochajs.org/)
+JavaScript testing and [nyc](https://github.com/istanbuljs/nyc) coverage-tooling to
+generate the coverage artifact:
+
+```yaml
+test:
+  script:
+    - npm install
+    - npx nyc --reporter cobertura mocha
+  artifacts:
+    reports:
+      coverage_report:
+        coverage_format: cobertura
+        path: coverage/cobertura-coverage.xml
+```
+
+### Java and Kotlin examples
+
+#### Maven example
+
+The following [`.gitlab-ci.yml`](../yaml/index.md) example for Java or Kotlin 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.
+
+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: 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 choose an existing stage like `deploy`.
+  stage: visualize
+  image: registry.gitlab.com/haynes/jacoco2cobertura:1.0.7
+  script:
+    # convert report from jacoco to cobertura, using relative project path
+    - python /opt/cover2cover.py target/site/jacoco/jacoco.xml $CI_PROJECT_DIR/src/main/java/ > target/site/cobertura.xml
+  needs: ["test-jdk11"]
+  artifacts:
+    reports:
+      coverage_report:
+        coverage_format: cobertura
+        path: target/site/cobertura.xml
+```
+
+#### Gradle example
+
+The following [`.gitlab-ci.yml`](../yaml/index.md) example for Java or Kotlin 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: registry.gitlab.com/haynes/jacoco2cobertura:1.0.7
+  script:
+    # convert report from jacoco to cobertura, using relative project path
+    - python /opt/cover2cover.py build/jacoco/jacoco.xml $CI_PROJECT_DIR/src/main/java/ > build/cobertura.xml
+  needs: ["test-jdk11"]
+  artifacts:
+    reports:
+      coverage_report:
+        coverage_format: cobertura
+        path: build/cobertura.xml
+```
+
+### Python example
+
+The following [`.gitlab-ci.yml`](../yaml/index.md) example for Python uses [pytest-cov](https://pytest-cov.readthedocs.io/) to collect test coverage data and [coverage.py](https://coverage.readthedocs.io/) to convert the report to use full relative paths.
+The information isn't displayed without the conversion.
+
+This example assumes that the code for your package is in `src/` and your tests are in `tests.py`:
+
+```yaml
+run tests:
+  stage: test
+  image: python:3
+  script:
+    - pip install pytest pytest-cov
+    - coverage run -m pytest
+    - coverage report
+    - coverage xml
+  coverage: '/(?i)total.*? (100(?:\.0+)?\%|[1-9]?\d(?:\.\d+)?\%)$/'
+  artifacts:
+    reports:
+      coverage_report:
+        coverage_format: cobertura
+        path: coverage.xml
+```
+
+### PHP example
+
+The following [`.gitlab-ci.yml`](../yaml/index.md) example for PHP uses [PHPUnit](https://phpunit.readthedocs.io/)
+to collect test coverage data and generate the report.
+
+With a minimal [`phpunit.xml`](https://phpunit.readthedocs.io/en/9.5/configuration.html) file (you may reference
+[this example repository](https://gitlab.com/yookoala/code-coverage-visualization-with-php/)), you can run the test and
+generate the `coverage.xml`:
+
+```yaml
+run tests:
+  stage: test
+  image: php:latest
+  variables:
+    XDEBUG_MODE: coverage
+  before_script:
+    - apt-get update && apt-get -yq install git unzip zip libzip-dev zlib1g-dev
+    - docker-php-ext-install zip
+    - pecl install xdebug && docker-php-ext-enable xdebug
+    - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
+    - php composer-setup.php --install-dir=/usr/local/bin --filename=composer
+    - composer install
+    - composer require --dev phpunit/phpunit phpunit/php-code-coverage
+  script:
+    - php ./vendor/bin/phpunit --coverage-text --coverage-cobertura=coverage.cobertura.xml
+  artifacts:
+    reports:
+      coverage_report:
+        coverage_format: cobertura
+        path: coverage.cobertura.xml
+```
+
+[Codeception](https://codeception.com/), through PHPUnit, also supports generating Cobertura report with
+[`run`](https://codeception.com/docs/reference/Commands#run). The path for the generated file
+depends on the `--coverage-cobertura` option and [`paths`](https://codeception.com/docs/reference/Configuration#paths)
+configuration for the [unit test suite](https://codeception.com/docs/05-UnitTests). Configure `.gitlab-ci.yml`
+to find Cobertura in the appropriate path.
+
+### C/C++ example
+
+The following [`.gitlab-ci.yml`](../yaml/index.md) example for C/C++ with
+`gcc` or `g++` as the compiler uses [`gcovr`](https://gcovr.com/en/stable/) to generate the coverage
+output file in Cobertura XML format.
+
+This example assumes:
+
+- That the `Makefile` is created by `cmake` in the `build` directory,
+  within another job in a previous stage.
+  (If you use `automake` to generate the `Makefile`,
+  then you need to call `make check` instead of `make test`.)
+- `cmake` (or `automake`) has set the compiler option `--coverage`.
+
+```yaml
+run tests:
+  stage: test
+  script:
+    - cd build
+    - make test
+    - gcovr --xml-pretty --exclude-unreachable-branches --print-summary -o coverage.xml --root ${CI_PROJECT_DIR}
+  coverage: /^\s*lines:\s*\d+.\d+\%/
+  artifacts:
+    name: ${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}-${CI_COMMIT_SHA}
+    expire_in: 2 days
+    reports:
+      coverage_report:
+        coverage_format: cobertura
+        path: build/coverage.xml
+```
+
+### Go example
+
+The following [`.gitlab-ci.yml`](../yaml/index.md) example for Go uses:
+
+- [`go test`](https://go.dev/doc/tutorial/add-a-test) to run tests.
+- [`gocover-cobertura`](https://github.com/boumenot/gocover-cobertura) to convert Go's coverage profile into the Cobertura XML format.
+
+This example assumes that [Go modules](https://go.dev/ref/mod)
+are being used. Please note that the `-covermode count` option does not work with the `-race` flag.
+If you want to generate code coverage while also using the `-race` flag, you must switch to
+`-covermode atomic` which is slower than `-covermode count`. See [this blog post](https://go.dev/blog/cover)
+for more details.
+
+```yaml
+run tests:
+  stage: test
+  image: golang:1.17
+  script:
+    - go install
+    - go test ./... -coverprofile=coverage.txt -covermode count
+    - go get github.com/boumenot/gocover-cobertura
+    - go run github.com/boumenot/gocover-cobertura < coverage.txt > coverage.xml
+  artifacts:
+    reports:
+      coverage_report:
+        coverage_format: cobertura
+        path: coverage.xml
+```
+
+### Ruby example
+
+The following [`.gitlab-ci.yml`](../yaml/index.md) example for Ruby uses
+
+- [`rspec`](https://rspec.info/) to run tests.
+- [`simplecov`](https://github.com/simplecov-ruby/simplecov) and [`simplecov-cobertura`](https://github.com/dashingrocket/simplecov-cobertura)
+  to record the coverage profile and create a report in the Cobertura XML format.
+
+This example assumes:
+
+- That [`bundler`](https://bundler.io/) is being used for dependency management.
+  The `rspec`, `simplecov` and `simplecov-cobertura` gems have been added to your `Gemfile`.
+- The `CoberturaFormatter` has been added to your `SimpleCov.formatters`
+  configuration within the `spec_helper.rb` file.
+
+```yaml
+run tests:
+  stage: test
+  image: ruby:3.1
+  script:
+    - bundle install
+    - bundle exec rspec
+  artifacts:
+    reports:
+      coverage_report:
+        coverage_format: cobertura
+        path: coverage/coverage.xml
+```
+
+## Troubleshooting
+
+### Test coverage visualization not displayed
+
+If the test coverage visualization is not displayed in the diff view, you can check
+the coverage report itself and verify that:
+
+- The file you are viewing in the diff view is mentioned in the coverage report.
+- The `source` and `filename` nodes in the report follows the [expected structure](#automatic-class-path-correction)
+  to match the files in your repository.
+
+Report artifacts are not downloadable by default. If you want the report to be downloadable
+from the job details page, add your coverage report to the artifact `paths`:
+
+```yaml
+artifacts:
+  paths:
+    - coverage/cobertura-coverage.xml
+  reports:
+    coverage_report:
+      coverage_format: cobertura
+      path: coverage/cobertura-coverage.xml
+```
diff --git a/doc/ci/testing/unit_test_reports.md b/doc/ci/testing/unit_test_reports.md
index 8aa41cd6fc0..c8e0d6135df 100644
--- a/doc/ci/testing/unit_test_reports.md
+++ b/doc/ci/testing/unit_test_reports.md
@@ -145,8 +145,9 @@ GitLab does not parse very [large nodes](https://nokogiri.org/tutorials/parsing_
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202114) in GitLab 13.0 behind the `:junit_pipeline_screenshots_view` feature flag, disabled by default.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/216979) in GitLab 13.12.
 
-Upload your screenshots as [artifacts](../yaml/artifacts_reports.md#artifactsreportsjunit) to GitLab. If JUnit
-report format XML files contain an `attachment` tag, GitLab parses the attachment. Note that:
+You can upload your screenshots as [artifacts](../yaml/artifacts_reports.md#artifactsreportsjunit) to GitLab.
+If JUnit report format XML files contain an `attachment` tag, GitLab parses the attachment.
+When uploading screenshot artifacts:
 
 - The `attachment` tag **must** contain the relative path to `$CI_PROJECT_DIR` of the screenshots you uploaded. For
   example:
@@ -161,5 +162,18 @@ report format XML files contain an `attachment` tag, GitLab parses the attachmen
   [`artifacts:when: always`](../yaml/index.md#artifactswhen) so that it still uploads a screenshot
   when a test fails.
 
-A link to the test case attachment appears in the test case details in
-[the pipeline test report](#view-unit-test-reports-on-gitlab).
+After the attachment is uploaded, [the pipeline test report](#view-unit-test-reports-on-gitlab)
+contains a link to the screenshot, for example:
+
+![Unit test report screenshot example](img/unit_test_report_screenshot_v13_12.png)
+
+## Troubleshooting
+
+### Test report appears empty
+
+A unit test report can appear to be empty when [viewed in a merge request](#view-unit-test-reports-on-gitlab)
+if the artifact that contained the report [expires](../yaml/index.md#artifactsexpire_in).
+If the artifact frequently expires too early, set a longer `expire_in` value for
+the report artifact.
+
+Alternatively, you can run a new pipeline to generate a new report.
diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md
index 8d8afbffab9..0230aaf7113 100644
--- a/doc/ci/troubleshooting.md
+++ b/doc/ci/troubleshooting.md
@@ -361,6 +361,29 @@ When you visit the job log page for a running job, there could be a delay of up
 60 seconds before the log updates. The default refresh time is 60 seconds, but after
 the log is viewed in the UI, the following log updates should occur every 3 seconds.
 
+## Disaster recovery
+
+You can disable some important but computationally expensive parts of the application
+to relieve stress on the database during ongoing downtime.
+
+### Disable fair scheduling on shared runners
+
+When clearing a large backlog of jobs, you can temporarily enable the `ci_queueing_disaster_recovery_disable_fair_scheduling`
+[feature flag](../administration/feature_flags.md). This flag disables fair scheduling
+on shared runners, which reduces system resource usage on the `jobs/request` endpoint.
+
+When enabled, jobs are processed in the order they were put in the system, instead of
+balanced across many projects.
+
+### Disable CI/CD minutes quota enforcement
+
+To disable the enforcement of CI/CD minutes quotas on shared runners, you can temporarily
+enable the `ci_queueing_disaster_recovery_disable_quota` [feature flag](../administration/feature_flags.md).
+This flag reduces system resource usage on the `jobs/request` endpoint.
+
+When enabled, jobs created in the last hour can run in projects which are out of quota.
+Earlier jobs are already canceled by a periodic background worker (`StuckCiJobsWorker`).
+
 ## How to get help
 
 If you are unable to resolve pipeline issues, you can get help from:
diff --git a/doc/ci/variables/index.md b/doc/ci/variables/index.md
index c53fad69376..72df8d56815 100644
--- a/doc/ci/variables/index.md
+++ b/doc/ci/variables/index.md
@@ -346,7 +346,7 @@ To mask a variable:
 1. Select the **Mask variable** checkbox.
 1. Select **Update variable**.
 
-The method used to mask variables [limits what can be included in a masked variable](](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/13784#note_106756757)).
+The method used to mask variables [limits what can be included in a masked variable](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/13784#note_106756757).
 The value of the variable must:
 
 - Be a single line.
@@ -401,6 +401,8 @@ Review all merge requests that introduce changes to the `.gitlab-ci.yml` file be
 - [Run a pipeline in the parent project for a merge request submitted from a forked project](../pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project).
 - Merge the changes.
 
+Review the `.gitlab-ci.yml` file of imported projects before you add files or run pipelines against them.
+
 The following example shows malicious code in a `.gitlab-ci.yml` file:
 
 ```yaml
diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md
index e6d61ef342b..6df614c1cda 100644
--- a/doc/ci/variables/predefined_variables.md
+++ b/doc/ci/variables/predefined_variables.md
@@ -29,7 +29,7 @@ as it can cause the pipeline to behave unexpectedly.
 | `CI_API_V4_URL`                          | 11.7   | all    | The GitLab API v4 root URL. |
 | `CI_BUILDS_DIR`                          | all    | 11.10  | The top-level directory where builds are executed. |
 | `CI_COMMIT_AUTHOR`                       | 13.11  | all    | The author of the commit in `Name <email>` format. |
-| `CI_COMMIT_BEFORE_SHA`                   | 11.2   | all    | The previous latest commit present on a branch. Is always `0000000000000000000000000000000000000000` in merge request pipelines. |
+| `CI_COMMIT_BEFORE_SHA`                   | 11.2   | all    | The previous latest commit present on a branch or tag. Is always `0000000000000000000000000000000000000000` in merge request pipelines and for the first commit in pipelines for branches or tags. |
 | `CI_COMMIT_BRANCH`                       | 12.6   | 0.5    | The commit branch name. Available in branch pipelines, including pipelines for the default branch. Not available in merge request pipelines or tag pipelines. |
 | `CI_COMMIT_DESCRIPTION`                  | 10.8   | all    | The description of the commit. If the title is shorter than 100 characters, the message without the first line. |
 | `CI_COMMIT_MESSAGE`                      | 10.8   | all    | The full commit message. |
@@ -139,29 +139,30 @@ These variables are available when:
 - The pipelines [are merge request pipelines](../pipelines/merge_request_pipelines.md).
 - The merge request is open.
 
-| Variable                               | GitLab | Runner | Description |
-|----------------------------------------|--------|--------|-------------|
-| `CI_MERGE_REQUEST_APPROVED`            | 14.1   | all    | Approval status of the merge request. `true` when [merge request approvals](../../user/project/merge_requests/approvals/index.md) is available and the merge request has been approved. |
-| `CI_MERGE_REQUEST_ASSIGNEES`           | 11.9   | all    | Comma-separated list of usernames of assignees for the merge request. |
-| `CI_MERGE_REQUEST_ID`                  | 11.6   | all    | The instance-level ID of the merge request. This is a unique ID across all projects on GitLab. |
-| `CI_MERGE_REQUEST_IID`                 | 11.6   | all    | The project-level IID (internal ID) of the merge request. This ID is unique for the current project. |
-| `CI_MERGE_REQUEST_LABELS`              | 11.9   | all    | Comma-separated label names of the merge request. |
-| `CI_MERGE_REQUEST_MILESTONE`           | 11.9   | all    | The milestone title of the merge request. |
-| `CI_MERGE_REQUEST_PROJECT_ID`          | 11.6   | all    | The ID of the project of the merge request. |
-| `CI_MERGE_REQUEST_PROJECT_PATH`        | 11.6   | all    | The path of the project of the merge request. For example `namespace/awesome-project`. |
-| `CI_MERGE_REQUEST_PROJECT_URL`         | 11.6   | all    | The URL of the project of the merge request. For example, `http://192.168.10.15:3000/namespace/awesome-project`. |
-| `CI_MERGE_REQUEST_REF_PATH`            | 11.6   | all    | The ref path of the merge request. For example, `refs/merge-requests/1/head`. |
-| `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME`  | 11.6   | all    | The source branch name of the merge request. |
-| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA`   | 11.9   | all    | The HEAD SHA of the source branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/merged_results_pipelines.md). |
-| `CI_MERGE_REQUEST_SOURCE_PROJECT_ID`   | 11.6   | all    | The ID of the source project of the merge request. |
-| `CI_MERGE_REQUEST_SOURCE_PROJECT_PATH` | 11.6   | all    | The path of the source project of the merge request. |
-| `CI_MERGE_REQUEST_SOURCE_PROJECT_URL`  | 11.6   | all    | The URL of the source project of the merge request. |
-| `CI_MERGE_REQUEST_TARGET_BRANCH_NAME`  | 11.6   | all    | The target branch name of the merge request. |
-| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA`   | 11.9   | all    | The HEAD SHA of the target branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/merged_results_pipelines.md). |
-| `CI_MERGE_REQUEST_TITLE`               | 11.9   | all    | The title of the merge request. |
-| `CI_MERGE_REQUEST_EVENT_TYPE`          | 12.3   | all    | The event type of the merge request. Can be `detached`, `merged_result` or `merge_train`. |
-| `CI_MERGE_REQUEST_DIFF_ID`             | 13.7   | all    | The version of the merge request diff. |
-| `CI_MERGE_REQUEST_DIFF_BASE_SHA`       | 13.7   | all    | The base SHA of the merge request diff. |
+| Variable                                    | GitLab | Runner | Description |
+|---------------------------------------------|--------|--------|-------------|
+| `CI_MERGE_REQUEST_APPROVED`                 | 14.1   | all    | Approval status of the merge request. `true` when [merge request approvals](../../user/project/merge_requests/approvals/index.md) is available and the merge request has been approved. |
+| `CI_MERGE_REQUEST_ASSIGNEES`                | 11.9   | all    | Comma-separated list of usernames of assignees for the merge request. |
+| `CI_MERGE_REQUEST_ID`                       | 11.6   | all    | The instance-level ID of the merge request. This is a unique ID across all projects on GitLab. |
+| `CI_MERGE_REQUEST_IID`                      | 11.6   | all    | The project-level IID (internal ID) of the merge request. This ID is unique for the current project. |
+| `CI_MERGE_REQUEST_LABELS`                   | 11.9   | all    | Comma-separated label names of the merge request. |
+| `CI_MERGE_REQUEST_MILESTONE`                | 11.9   | all    | The milestone title of the merge request. |
+| `CI_MERGE_REQUEST_PROJECT_ID`               | 11.6   | all    | The ID of the project of the merge request. |
+| `CI_MERGE_REQUEST_PROJECT_PATH`             | 11.6   | all    | The path of the project of the merge request. For example `namespace/awesome-project`. |
+| `CI_MERGE_REQUEST_PROJECT_URL`              | 11.6   | all    | The URL of the project of the merge request. For example, `http://192.168.10.15:3000/namespace/awesome-project`. |
+| `CI_MERGE_REQUEST_REF_PATH`                 | 11.6   | all    | The ref path of the merge request. For example, `refs/merge-requests/1/head`. |
+| `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME`       | 11.6   | all    | The source branch name of the merge request. |
+| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA`        | 11.9   | all    | The HEAD SHA of the source branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/merged_results_pipelines.md). |
+| `CI_MERGE_REQUEST_SOURCE_PROJECT_ID`        | 11.6   | all    | The ID of the source project of the merge request. |
+| `CI_MERGE_REQUEST_SOURCE_PROJECT_PATH`      | 11.6   | all    | The path of the source project of the merge request. |
+| `CI_MERGE_REQUEST_SOURCE_PROJECT_URL`       | 11.6   | all    | The URL of the source project of the merge request. |
+| `CI_MERGE_REQUEST_TARGET_BRANCH_NAME`       | 11.6   | all    | The target branch name of the merge request. |
+| `CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED`  | 15.2   | all    | The protection status for the target branch of the merge request. |
+| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA`        | 11.9   | all    | The HEAD SHA of the target branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/merged_results_pipelines.md). |
+| `CI_MERGE_REQUEST_TITLE`                    | 11.9   | all    | The title of the merge request. |
+| `CI_MERGE_REQUEST_EVENT_TYPE`               | 12.3   | all    | The event type of the merge request. Can be `detached`, `merged_result` or `merge_train`. |
+| `CI_MERGE_REQUEST_DIFF_ID`                  | 13.7   | all    | The version of the merge request diff. |
+| `CI_MERGE_REQUEST_DIFF_BASE_SHA`            | 13.7   | all    | The base SHA of the merge request diff. |
 
 ## Predefined variables for external pull request pipelines
 
diff --git a/doc/ci/yaml/artifacts_reports.md b/doc/ci/yaml/artifacts_reports.md
index e4324ab06e1..379a4b3224a 100644
--- a/doc/ci/yaml/artifacts_reports.md
+++ b/doc/ci/yaml/artifacts_reports.md
@@ -36,9 +36,9 @@ The `accessibility` report uses [pa11y](https://pa11y.org/) to report on the acc
 of changes introduced in merge requests.
 
 GitLab can display the results of one or more reports in the merge request
-[accessibility widget](../../user/project/merge_requests/accessibility_testing.md#accessibility-merge-request-widget).
+[accessibility widget](../testing/accessibility_testing.md#accessibility-merge-request-widget).
 
-For more information, see [Accessibility testing](../../user/project/merge_requests/accessibility_testing.md).
+For more information, see [Accessibility testing](../testing/accessibility_testing.md).
 
 ## `artifacts:reports:api_fuzzing` **(ULTIMATE)**
 
@@ -52,18 +52,18 @@ GitLab can display the results of one or more reports in:
 
 - The merge request [security widget](../../user/application_security/api_fuzzing/index.md#view-details-of-an-api-fuzzing-vulnerability).
 - The [Project Vulnerability report](../../user/application_security/vulnerability_report/index.md).
-- The pipeline [**Security** tab](../../user/application_security/security_dashboard/index.md#view-vulnerabilities-in-a-pipeline).
+- The pipeline [**Security** tab](../../user/application_security/vulnerability_report/pipeline.md#view-vulnerabilities-in-a-pipeline).
 - The [security dashboard](../../user/application_security/api_fuzzing/index.md#security-dashboard).
 
 ## `artifacts:reports:browser_performance` **(PREMIUM)**
 
 > [Name changed](https://gitlab.com/gitlab-org/gitlab/-/issues/225914) from `artifacts:reports:performance` in GitLab 14.0.
 
-The `browser_performance` report collects [Browser Performance Testing metrics](../../user/project/merge_requests/browser_performance_testing.md)
+The `browser_performance` report collects [Browser Performance Testing metrics](../testing/browser_performance_testing.md)
 as artifacts.
 
 GitLab can display the results of one report in the merge request
-[browser performance testing widget](../../user/project/merge_requests/browser_performance_testing.md#how-browser-performance-testing-works).
+[browser performance testing widget](../testing/browser_performance_testing.md#how-browser-performance-testing-works).
 
 GitLab cannot display the combined results of multiple `browser_performance` reports.
 
@@ -100,7 +100,7 @@ instead.
 
 Use `coverage_report` to collect coverage report in Cobertura format.
 
-The `cobertura` report collects [Cobertura coverage XML files](../../user/project/merge_requests/test_coverage_visualization.md).
+The `cobertura` report collects [Cobertura coverage XML files](../testing/test_coverage_visualization.md).
 
 Cobertura was originally developed for Java, but there are many third-party ports for other languages such as
 JavaScript, Python, and Ruby.
@@ -116,22 +116,22 @@ artifacts:
 The collected coverage report is uploaded to GitLab as an artifact.
 
 GitLab can display the results of coverage report in the merge request
-[diff annotations](../../user/project/merge_requests/test_coverage_visualization.md).
+[diff annotations](../testing/test_coverage_visualization.md).
 
 ## `artifacts:reports:codequality`
 
 > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) to GitLab Free in 13.2.
 
-The `codequality` report collects [code quality issues](../../user/project/merge_requests/code_quality.md). The
+The `codequality` report collects [code quality issues](../testing/code_quality.md). The
 collected code quality report uploads to GitLab as an artifact.
 
 GitLab can display the results of:
 
-- One or more reports in the merge request [code quality widget](../../user/project/merge_requests/code_quality.md#code-quality-widget).
+- One or more reports in the merge request [code quality widget](../testing/code_quality.md#code-quality-widget).
 - Only one report in:
-  - The merge request [diff annotations](../../user/project/merge_requests/code_quality.md#code-quality-in-diff-view).
+  - The merge request [diff annotations](../testing/code_quality.md#code-quality-in-diff-view).
     Track progress on adding support for multiple reports in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328257).
-  - The [full report](../metrics_reports.md). Track progress on adding support for multiple reports in
+  - The [full report](../testing/metrics_reports.md). Track progress on adding support for multiple reports in
     [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/9014).
 
 ## `artifacts:reports:container_scanning` **(ULTIMATE)**
@@ -142,7 +142,7 @@ The collected Container Scanning report uploads to GitLab as an artifact.
 GitLab can display the results of one or more reports in:
 
 - The merge request [container scanning widget](../../user/application_security/container_scanning/index.md).
-- The pipeline [**Security** tab](../../user/application_security/security_dashboard/index.md#view-vulnerabilities-in-a-pipeline).
+- The pipeline [**Security** tab](../../user/application_security/vulnerability_report/pipeline.md#view-vulnerabilities-in-a-pipeline).
 - The [security dashboard](../../user/application_security/security_dashboard/index.md).
 - The [Project Vulnerability report](../../user/application_security/vulnerability_report/index.md).
 
@@ -156,7 +156,7 @@ The collected coverage fuzzing report uploads to GitLab as an artifact.
 GitLab can display the results of one or more reports in:
 
 - The merge request [coverage fuzzing widget](../../user/application_security/coverage_fuzzing/index.md#interacting-with-the-vulnerabilities).
-- The pipeline [**Security** tab](../../user/application_security/security_dashboard/index.md#view-vulnerabilities-in-a-pipeline).
+- The pipeline [**Security** tab](../../user/application_security/vulnerability_report/pipeline.md#view-vulnerabilities-in-a-pipeline).
 - The [Project Vulnerability report](../../user/application_security/vulnerability_report/index.md).
 - The [security dashboard](../../user/application_security/security_dashboard/index.md).
 
@@ -168,7 +168,7 @@ report uploads to GitLab as an artifact.
 GitLab can display the results of one or more reports in:
 
 - The merge request [security widget](../../user/application_security/dast/index.md#view-details-of-a-vulnerability-detected-by-dast).
-- The pipeline [**Security** tab](../../user/application_security/security_dashboard/index.md#view-vulnerabilities-in-a-pipeline).
+- The pipeline [**Security** tab](../../user/application_security/vulnerability_report/pipeline.md#view-vulnerabilities-in-a-pipeline).
 - The [Project Vulnerability report](../../user/application_security/vulnerability_report/index.md).
 - The [security dashboard](../../user/application_security/security_dashboard/index.md).
 
@@ -180,7 +180,7 @@ The collected Dependency Scanning report uploads to GitLab as an artifact.
 GitLab can display the results of one or more reports in:
 
 - The merge request [dependency scanning widget](../../user/application_security/dependency_scanning/index.md).
-- The pipeline [**Security** tab](../../user/application_security/security_dashboard/index.md#view-vulnerabilities-in-a-pipeline).
+- The pipeline [**Security** tab](../../user/application_security/vulnerability_report/pipeline.md#view-vulnerabilities-in-a-pipeline).
 - The [security dashboard](../../user/application_security/security_dashboard/index.md).
 - The [Project Vulnerability report](../../user/application_security/vulnerability_report/index.md).
 - The [dependency list](../../user/application_security/dependency_list/).
@@ -213,6 +213,7 @@ The exceptions to the [original dotenv rules](https://github.com/motdotla/dotenv
 - The `.env` file can't have empty lines or comments (starting with `#`).
 - Key values in the `env` file cannot have spaces or newline characters (`\n`), including when using single or double quotes.
 - Quote escaping during parsing (`key = 'value'` -> `{key: "value"}`) is not supported.
+- Only UTF-8 encoding is [supported](../pipelines/job_artifacts.md#error-message-fatal-invalid-argument-when-uploading-a-dotenv-artifact-on-a-windows-runner).
 
 ## `artifacts:reports:junit`
 
@@ -263,25 +264,25 @@ GitLab can display the results of one or more reports in:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35260) in GitLab 13.2.
 > - Requires GitLab Runner 11.5 and above.
 
-The `load_performance` report collects [Load Performance Testing metrics](../../user/project/merge_requests/load_performance_testing.md).
+The `load_performance` report collects [Load Performance Testing metrics](../testing/load_performance_testing.md).
 The report is uploaded to GitLab as an artifact.
 
 GitLab can display the results of only one report in the merge request
-[load testing widget](../../user/project/merge_requests/load_performance_testing.md#how-load-performance-testing-works).
+[load testing widget](../testing/load_performance_testing.md#how-load-performance-testing-works).
 
 GitLab cannot display the combined results of multiple `load_performance` reports.
 
 ## `artifacts:reports:metrics` **(PREMIUM)**
 
-The `metrics` report collects [Metrics](../metrics_reports.md). The collected Metrics report uploads to GitLab as an
+The `metrics` report collects [Metrics](../testing/metrics_reports.md). The collected Metrics report uploads to GitLab as an
 artifact.
 
 GitLab can display the results of one or more reports in the merge request
-[metrics reports widget](../../ci/metrics_reports.md#metrics-reports).
+[metrics reports widget](../testing/metrics_reports.md#metrics-reports).
 
 ## `artifacts:reports:requirements` **(ULTIMATE)**
 
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2859) in GitLab 13.1.
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2859) in GitLab 13.1.
 
 The `requirements` report collects `requirements.json` files. The collected Requirements report uploads to GitLab as an
 artifact and existing [requirements](../../user/project/requirements/index.md) are marked as Satisfied.
@@ -291,7 +292,7 @@ GitLab can display the results of one or more reports in the
 
 ## `artifacts:reports:sast`
 
-> - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/2098) from GitLab Ultimate to GitLab Free in 13.3.
+> [Moved](https://gitlab.com/groups/gitlab-org/-/epics/2098) from GitLab Ultimate to GitLab Free in 13.3.
 
 The `sast` report collects [SAST vulnerabilities](../../user/application_security/sast/index.md). The collected SAST
 report uploads to GitLab as an artifact.
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 912eca364c9..3bb2007d6e3 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -675,6 +675,45 @@ artifacts are restored after [caches](#cache).
 
 [Read more about artifacts](../pipelines/job_artifacts.md).
 
+#### `artifacts:paths`
+
+Paths are relative to the project directory (`$CI_PROJECT_DIR`) and can't directly
+link outside it.
+
+**Keyword type**: Job keyword. You can use it only as part of a job or in the
+[`default` section](#default).
+
+**Possible inputs**:
+
+- An array of file paths, relative to the project directory.
+- You can use Wildcards that use [glob](https://en.wikipedia.org/wiki/Glob_(programming))
+  patterns and:
+  - In [GitLab Runner 13.0 and later](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2620),
+    [`doublestar.Glob`](https://pkg.go.dev/github.com/bmatcuk/doublestar@v1.2.2?tab=doc#Match).
+  - In GitLab Runner 12.10 and earlier, [`filepath.Match`](https://pkg.go.dev/path/filepath#Match).
+
+**Example of `artifacts:paths`**:
+
+```yaml
+job:
+  artifacts:
+    paths:
+      - binaries/
+      - .config
+```
+
+This example creates an artifact with `.config` and all the files in the `binaries` directory.
+
+**Additional details**:
+
+- If not used with [`artifacts:name`](#artifactsname), the artifacts file
+  is named `artifacts`, which becomes `artifacts.zip` when downloaded.
+
+**Related topics**:
+
+- To restrict which jobs a specific job fetches artifacts from, see [`dependencies`](#dependencies).
+- [Create job artifacts](../pipelines/job_artifacts.md#create-job-artifacts).
+
 #### `artifacts:exclude`
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15122) in GitLab 13.1
@@ -843,45 +882,6 @@ job:
 
 - [Use CI/CD variables to define the artifacts name](../pipelines/job_artifacts.md#use-cicd-variables-to-define-the-artifacts-name).
 
-#### `artifacts:paths`
-
-Paths are relative to the project directory (`$CI_PROJECT_DIR`) and can't directly
-link outside it.
-
-**Keyword type**: Job keyword. You can use it only as part of a job or in the
-[`default` section](#default).
-
-**Possible inputs**:
-
-- An array of file paths, relative to the project directory.
-- You can use Wildcards that use [glob](https://en.wikipedia.org/wiki/Glob_(programming))
-  patterns and:
-  - In [GitLab Runner 13.0 and later](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2620),
-    [`doublestar.Glob`](https://pkg.go.dev/github.com/bmatcuk/doublestar@v1.2.2?tab=doc#Match).
-  - In GitLab Runner 12.10 and earlier, [`filepath.Match`](https://pkg.go.dev/path/filepath#Match).
-
-**Example of `artifacts:paths`**:
-
-```yaml
-job:
-  artifacts:
-    paths:
-      - binaries/
-      - .config
-```
-
-This example creates an artifact with `.config` and all the files in the `binaries` directory.
-
-**Additional details**:
-
-- If not used with [`artifacts:name`](#artifactsname) defined, the artifacts file
-  is named `artifacts`, which becomes `artifacts.zip` when downloaded.
-
-**Related topics**:
-
-- To restrict which jobs a specific job fetches artifacts from, see [`dependencies`](#dependencies).
-- [Create job artifacts](../pipelines/job_artifacts.md#create-job-artifacts).
-
 #### `artifacts:public`
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49775) in GitLab 13.8
@@ -910,7 +910,7 @@ pipelines, set `artifacts:public` to `false`:
 
 - `true` (default if not defined) or `false`.
 
-**Example of `artifacts:paths`**:
+**Example of `artifacts:public`**:
 
 ```yaml
 job:
@@ -1099,6 +1099,8 @@ that use the same cache key use the same cache, including in different pipelines
 If not set, the default key is `default`. All jobs with the `cache` keyword but
 no `cache:key` share the `default` cache.
 
+Must be used with `cache: path`, or nothing is cached.
+
 **Keyword type**: Job keyword. You can use it only as part of a job or in the
 [`default` section](#default).
 
@@ -1263,6 +1265,8 @@ rspec:
 
 Use `cache:when` to define when to save the cache, based on the status of the job.
 
+Must be used with `cache: path`, or nothing is cached.
+
 **Keyword type**: Job keyword. You can use it only as part of a job or in the
 [`default` section](#default).
 
@@ -1301,6 +1305,8 @@ Use the `pull` policy when you have many jobs executing in parallel that use the
 This policy speeds up job execution and reduces load on the cache server. You can
 use a job with the `push` policy to build the cache.
 
+Must be used with `cache: path`, or nothing is cached.
+
 **Keyword type**: Job keyword. You can use it only as part of a job or in the
 [`default` section](#default).
 
@@ -2204,6 +2210,7 @@ In this example:
 
 Use `needs:project` to download artifacts from up to five jobs in other pipelines.
 The artifacts are downloaded from the latest successful pipeline for the specified ref.
+To specify multiple jobs, add each as separate array items under the `needs` keyword.
 
 If there is a pipeline running for the specified ref, a job with `needs:project`
 does not wait for the pipeline to complete. Instead, the job downloads the artifact
@@ -2232,10 +2239,14 @@ build_job:
       job: build-1
       ref: main
       artifacts: true
+    - project: namespace/group/project-name-2
+      job: build-2
+      ref: main
+      artifacts: true
 ```
 
-In this example, `build_job` downloads the artifacts from the latest successful `build-1` job
-on the `main` branch in the `group/project-name` project.
+In this example, `build_job` downloads the artifacts from the latest successful `build-1` and `build-2` jobs
+on the `main` branches in the `group/project-name` and `group/project-name-2` projects.
 
 In GitLab 13.3 and later, you can use [CI/CD variables](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
 in `needs:project`, for example:
@@ -2428,13 +2439,6 @@ You can use `only` and `except` to control when to add jobs to pipelines.
 - Use `only` to define when a job runs.
 - Use `except` to define when a job **does not** run.
 
-Four keywords can be used with `only` and `except`:
-
-- [`refs`](#onlyrefs--exceptrefs)
-- [`variables`](#onlyvariables--exceptvariables)
-- [`changes`](#onlychanges--exceptchanges)
-- [`kubernetes`](#onlykubernetes--exceptkubernetes)
-
 See [specify when jobs run with `only` and `except`](../jobs/job_control.md#specify-when-jobs-run-with-only-and-except)
 for more details and examples.
 
@@ -2443,6 +2447,10 @@ for more details and examples.
 Use the `only:refs` and `except:refs` keywords to control when to add jobs to a
 pipeline based on branch names or pipeline types.
 
+`only:refs` and `except:refs` are not being actively developed. [`rules:if`](#rulesif)
+is the preferred keyword when using refs, regular expressions, or variables to control
+when to add jobs to pipelines.
+
 **Keyword type**: Job keyword. You can use it only as part of a job.
 
 **Possible inputs**: An array including any number of:
@@ -2519,8 +2527,8 @@ job2:
   job2:
     script: echo "test"
     only:
-    - branches
-    - tags
+      - branches
+      - tags
   ```
 
 #### `only:variables` / `except:variables`
@@ -2528,6 +2536,10 @@ job2:
 Use the `only:variables` or `except:variables` keywords to control when to add jobs
 to a pipeline, based on the status of [CI/CD variables](../variables/index.md).
 
+`only:variables` and `except:variables` are not being actively developed. [`rules:if`](#rulesif)
+is the preferred keyword when using refs, regular expressions, or variables to control
+when to add jobs to pipelines.
+
 **Keyword type**: Job keyword. You can use it only as part of a job.
 
 **Possible inputs**:
@@ -2560,6 +2572,9 @@ Use `changes` in pipelines with the following refs:
 - `external_pull_requests`
 - `merge_requests` (see additional details about [using `only:changes` with merge request pipelines](../jobs/job_control.md#use-onlychanges-with-merge-request-pipelines))
 
+`only:changes` and `except:changes` are not being actively developed. [`rules:changes`](#ruleschanges)
+is the preferred keyword when using changed files to control when to add jobs to pipelines.
+
 **Keyword type**: Job keyword. You can use it only as part of a job.
 
 **Possible inputs**: An array including any number of:
@@ -2610,6 +2625,10 @@ docker build:
 Use `only:kubernetes` or `except:kubernetes` to control if jobs are added to the pipeline
 when the Kubernetes service is active in the project.
 
+`only:refs` and `except:refs` are not being actively developed. Use [`rules:if`](#rulesif)
+with the [`CI_KUBERNETES_ACTIVE`](../variables/predefined_variables.md) predefined CI/CD variable
+to control if jobs are added to the pipeline when the Kubernetes service is active in the project.
+
 **Keyword type**: Job-specific. You can use it only as part of a job.
 
 **Possible inputs**:
@@ -3388,7 +3407,7 @@ This keyword must be used with `secrets:vault`.
 
 #### `secrets:vault`
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/28321) in GitLab 13.4 and GitLab Runner 13.4.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/28321) in GitLab 13.4 and GitLab Runner 13.4.
 
 Use `secrets:vault` to specify secrets provided by a [HashiCorp Vault](https://www.vaultproject.io/).
 
@@ -3519,6 +3538,52 @@ in that container.
 - [Run your CI/CD jobs in Docker containers](../docker/using_docker_images.md).
 - [Use Docker to build Docker images](../docker/using_docker_build.md).
 
+#### `service:pull_policy`
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/21619) in GitLab 15.1 [with a flag](../../administration/feature_flags.md) named `ci_docker_image_pull_policy`. Disabled by default.
+> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/363186) in GitLab 15.2.
+> - Requires GitLab Runner 15.1 or later.
+
+FLAG:
+On self-managed GitLab, by default this feature is available. To hide the feature,
+ask an administrator to [disable the feature flag](../../administration/feature_flags.md) named `ci_docker_image_pull_policy`.
+
+The pull policy that the runner uses to fetch the Docker image.
+
+**Keyword type**: Job keyword. You can use it only as part of a job or in the [`default` section](#default).
+
+**Possible inputs**:
+
+- A single pull policy, or multiple pull policies in an array.
+  Can be `always`, `if-not-present`, or `never`.
+
+**Examples of `service:pull_policy`**:
+
+```yaml
+job1:
+  script: echo "A single pull policy."
+  services:
+    - name: postgres:11.6
+      pull_policy: if-not-present
+
+job2:
+  script: echo "Multiple pull policies."
+  services:
+    - name: postgres:11.6
+      pull_policy: [always, if-not-present]
+```
+
+**Additional details**:
+
+- If the runner does not support the defined pull policy, the job fails with an error similar to:
+  `ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never])`.
+
+**Related topics**:
+
+- [Run your CI/CD jobs in Docker containers](../docker/using_docker_images.md).
+- [How runner pull policies work](https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work).
+- [Using multiple pull policies](https://docs.gitlab.com/runner/executors/docker.html#using-multiple-pull-policies).
+
 ### `stage`
 
 Use `stage` to define which [stage](#stages) a job runs in. Jobs in the same
diff --git a/doc/ci/yaml/workflow.md b/doc/ci/yaml/workflow.md
index a985db14d08..743a2639c0c 100644
--- a/doc/ci/yaml/workflow.md
+++ b/doc/ci/yaml/workflow.md
@@ -61,7 +61,7 @@ This example prevents pipelines for schedules or `push` (branches and tags) pipe
 The final `when: always` rule runs all other pipeline types, **including** merge
 request pipelines.
 
-## Switch between branch pipelines and merge request pipelines
+### Switch between branch pipelines and merge request pipelines
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) in GitLab 13.8.
 
@@ -115,6 +115,25 @@ set and could be blocked by a similar rule. Triggered pipelines have a pipeline
 of `trigger` or `pipeline`, so `&& $CI_PIPELINE_SOURCE == "push"` ensures the rule
 does not block triggered pipelines.
 
+### Git Flow with merge request pipelines
+
+You can use `workflow: rules` as part of [Git Flow or similar strategies](../../topics/gitlab_flow.md)
+with merge request pipelines. With these rules, you can use [merge request pipeline features](../pipelines/merge_request_pipelines.md)
+with feature branches, while keeping long-lived branches to support multiple versions
+of your software.
+
+For example, to only run pipelines for your merge requests, tags, and protected branches:
+
+```yaml
+workflow:
+  rules:
+    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
+    - if: $CI_COMMIT_TAG
+    - if: $CI_COMMIT_REF_PROTECTED
+```
+
+This example assumes that your long-lived branches are [protected](../../user/project/protected_branches.md).
+
 ## `workflow:rules` templates
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217732) in GitLab 13.0.
@@ -150,3 +169,23 @@ To [include](index.md#include) it:
 include:
   - template: 'Workflows/MergeRequest-Pipelines.gitlab-ci.yml'
 ```
+
+## Troubleshooting
+
+### Merge request stuck with `Checking pipeline status.` message
+
+If a merge request displays `Checking pipeline status.`, but the message never goes
+away (the "spinner" never stops spinning), it might be due to `workflow:rules`.
+This issue can happen if a project has [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds)
+enabled, but the `workflow:rules` prevent a pipeline from running for the merge request.
+
+For example, with this workflow, merge requests cannot be merged, because no
+pipeline can run:
+
+```yaml
+workflow:
+  rules:
+    - changes:
+      - .gitlab/**/**.md
+      when: never
+```