Add latest changes from gitlab-org/gitlab@14-4-stable-eev14.4.0-rc42

66 files changed, 561 insertions, 354 deletions

diff --git a/doc/ci/README.md b/doc/ci/README.md
deleted file mode 100644
index 0e6c2f63f9e..00000000000
--- a/doc/ci/README.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2021-09-28'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after 2021-09-28. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/chatops/index.md b/doc/ci/chatops/index.md
index a2d9cf9054d..698b467a813 100644
--- a/doc/ci/chatops/index.md
+++ b/doc/ci/chatops/index.md
@@ -9,6 +9,7 @@ type: index, concepts, howto
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4466) in GitLab Ultimate 10.6.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24780) to GitLab Free in 11.9.
+> - `CHAT_USER_ID` was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/341798) in GitLab 14.4.
 
 GitLab ChatOps provides a method to interact with CI/CD jobs through chat services
 like Slack. Many organizations' discussion, collaboration, and troubleshooting takes
@@ -17,7 +18,7 @@ posted back to the channel can significantly augment your team's workflow.
 
 ## How GitLab ChatOps works
 
-GitLab ChatOps is built upon [GitLab CI/CD](../README.md) and
+GitLab ChatOps is built upon [GitLab CI/CD](../index.md) and
 [Slack Slash Commands](../../user/project/integrations/slack_slash_commands.md).
 ChatOps provides a `run` action for [slash commands](../../integration/slash_commands.md)
 with the following arguments:
@@ -30,6 +31,7 @@ to the job:
 
 - `CHAT_INPUT` contains any additional arguments.
 - `CHAT_CHANNEL` is set to the name of channel the action was triggered in.
+- `CHAT_USER_ID` is set to the chat service's user ID of the user who triggered the slash command.
 
 When executed, ChatOps looks up the specified job name and attempts to match it
 to a corresponding job in [`.gitlab-ci.yml`](../yaml/index.md). If a matching job
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 e69daf6651a..cf4e846ebb4 100644
--- a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
+++ b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md
@@ -21,7 +21,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
 
    ![Create project](img/external_repository.png)
 
-   GitLab imports the repository and enables [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pull-from-a-remote-repository).
+   GitLab imports the repository and enables [Pull Mirroring](../../user/project/repository/mirror/pull.md).
 
 1. In GitLab, create a
    [Personal Access Token](../../user/profile/personal_access_tokens.md)
diff --git a/doc/ci/ci_cd_for_external_repos/github_integration.md b/doc/ci/ci_cd_for_external_repos/github_integration.md
index 70a9c8fc775..4e4b7420697 100644
--- a/doc/ci/ci_cd_for_external_repos/github_integration.md
+++ b/doc/ci/ci_cd_for_external_repos/github_integration.md
@@ -45,7 +45,7 @@ repositories:
 GitLab:
 
 1. Imports the project.
-1. Enables [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pull-from-a-remote-repository).
+1. Enables [Pull Mirroring](../../user/project/repository/mirror/pull.md).
 1. Enables [GitHub project integration](../../user/project/integrations/github.md).
 1. Creates a web hook on GitHub to notify GitLab of new commits.
 
diff --git a/doc/ci/ci_cd_for_external_repos/index.md b/doc/ci/ci_cd_for_external_repos/index.md
index 365e2ee31de..fbfcdcbf64f 100644
--- a/doc/ci/ci_cd_for_external_repos/index.md
+++ b/doc/ci/ci_cd_for_external_repos/index.md
@@ -18,7 +18,7 @@ GitLab CI/CD can be used with:
 Instead of moving your entire project to GitLab, you can connect your
 external repository to get the benefits of GitLab CI/CD.
 
-Connecting an external repository sets up [repository mirroring](../../user/project/repository/repository_mirroring.md)
+Connecting an external repository sets up [repository mirroring](../../user/project/repository/mirror/index.md)
 and create a lightweight project with issues, merge requests, wiki, and
 snippets disabled. These features
 [can be re-enabled later](../../user/project/settings/index.md#sharing-and-permissions).
diff --git a/doc/ci/cloud_deployment/index.md b/doc/ci/cloud_deployment/index.md
index 25b87366a30..408d68fb726 100644
--- a/doc/ci/cloud_deployment/index.md
+++ b/doc/ci/cloud_deployment/index.md
@@ -58,6 +58,9 @@ Some credentials are required to be able to run `aws` commands:
    | `AWS_SECRET_ACCESS_KEY`        | Your Secret access key |
    | `AWS_DEFAULT_REGION`           | Your region code       |
 
+   NOTE:
+   When you create a variable it's set to be [protected by default](../variables/index.md#protect-a-cicd-variable). If you want to use the `aws` commands on branches or tags that are not protected, make sure to uncheck the **Protect variable** checkbox.
+
 1. You can now use `aws` commands in the `.gitlab-ci.yml` file of this project:
 
    ```yaml
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index d5adedc611c..9a4290ead4c 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -572,7 +572,7 @@ The configuration is picked up by the `dind` service.
 ## Authenticate with registry in Docker-in-Docker
 
 When you use Docker-in-Docker, the
-[standard authentication methods](using_docker_images.md#define-an-image-from-a-private-container-registry)
+[standard authentication methods](using_docker_images.md#access-an-image-from-a-private-container-registry)
 don't work because a fresh Docker daemon is started with the service.
 
 ### Option 1: Run `docker login`
diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md
index c2991ce66f9..79c23d73a68 100644
--- a/doc/ci/docker/using_docker_images.md
+++ b/doc/ci/docker/using_docker_images.md
@@ -214,7 +214,7 @@ Look for the `[runners.docker]` section:
 The image and services defined this way are added to all jobs run by
 that runner.
 
-## Define an image from a private Container Registry
+## Access an image from a private Container Registry
 
 To access private container registries, the GitLab Runner process can use:
 
@@ -224,19 +224,12 @@ To access private container registries, the GitLab Runner process can use:
 
 To define which option should be used, the runner process reads the configuration in this order:
 
-- A `DOCKER_AUTH_CONFIG` variable provided as either:
-  - A [CI/CD variable](../variables/index.md) in the `.gitlab-ci.yml` file.
-  - A project's variables stored on the project's **Settings > CI/CD** page.
-- A `DOCKER_AUTH_CONFIG` variable provided as environment variable in the runner's `config.toml` file.
+- A `DOCKER_AUTH_CONFIG` [CI/CD variable](../variables/index.md).
+- A `DOCKER_AUTH_CONFIG` environment variable set in the runner's `config.toml` file.
 - A `config.json` file in `$HOME/.docker` directory of the user running the process.
   If the `--user` flag is provided to run the child processes as unprivileged user,
   the home directory of the main runner process user is used.
 
-The runner reads this configuration **only** from the `config.toml` file and ignores it if
-it's provided as a CI/CD variable. This is because the runner uses **only**
-`config.toml` configuration and does not interpolate **any** CI/CD variables at
-runtime.
-
 ### Requirements and limitations
 
 - Available for [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
@@ -253,9 +246,9 @@ private registry. Both require setting the CI/CD variable
 `DOCKER_AUTH_CONFIG` with appropriate authentication information.
 
 1. Per-job: To configure one job to access a private registry, add
-   `DOCKER_AUTH_CONFIG` as a job variable.
+   `DOCKER_AUTH_CONFIG` as a [CI/CD variable](../variables/index.md).
 1. Per-runner: To configure a runner so all its jobs can access a
-   private registry, add `DOCKER_AUTH_CONFIG` to the environment in the
+   private registry, add `DOCKER_AUTH_CONFIG` as an environment variable in the
    runner's configuration.
 
 See below for examples of each.
@@ -274,7 +267,7 @@ Let's also assume that these are the sign-in credentials:
 | username | `my_username`               |
 | password | `my_password`               |
 
-Use one of the following methods to determine the value of `DOCKER_AUTH_CONFIG`:
+Use one of the following methods to determine the value for `DOCKER_AUTH_CONFIG`:
 
 - Do a `docker login` on your local machine:
 
diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md
index 6886899a54b..69c4557dcbe 100644
--- a/doc/ci/docker/using_kaniko.md
+++ b/doc/ci/docker/using_kaniko.md
@@ -13,8 +13,8 @@ type: howto
 container images from a Dockerfile, inside a container or Kubernetes cluster.
 
 kaniko solves two problems with using the
-[Docker-in-Docker
-build](using_docker_build.md#use-the-docker-executor-with-the-docker-image-docker-in-docker) method:
+[Docker-in-Docker build](using_docker_build.md#use-the-docker-executor-with-the-docker-image-docker-in-docker)
+method:
 
 - Docker-in-Docker requires [privileged mode](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
   to function, which is a significant security concern.
@@ -64,7 +64,7 @@ build:
     entrypoint: [""]
   script:
     - mkdir -p /kaniko/.docker
-    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(echo -n ${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD} | base64)\"}}}" > /kaniko/.docker/config.json
+    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(echo -n ${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD} | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
     - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
   rules:
     - if: $CI_COMMIT_TAG
@@ -91,7 +91,7 @@ build:
     - mkdir -p /kaniko/.docker
     - |-
        KANIKOPROXYBUILDARGS=""
-       KANIKOCFG="{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(echo -n ${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD} | base64)\"}}}"
+       KANIKOCFG="{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(echo -n ${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD} | base64 | tr -d '\n')\"}}}"
        if [ "x${http_proxy}" != "x" -o "x${https_proxy}" != "x" ]; then
          KANIKOCFG="${KANIKOCFG}, \"proxies\": { \"default\": { \"httpProxy\": \"${http_proxy}\", \"httpsProxy\": \"${https_proxy}\", \"noProxy\": \"${no_proxy}\"}}"
          KANIKOPROXYBUILDARGS="--build-arg http_proxy=${http_proxy} --build-arg https_proxy=${https_proxy} --build-arg no_proxy=${no_proxy}"
@@ -120,7 +120,7 @@ store:
 ```yaml
 before_script:
   - mkdir -p /kaniko/.docker
-  - echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(echo -n ${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD} | base64)\"}}}" > /kaniko/.docker/config.json
+  - echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(echo -n ${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD} | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
   - |
     echo "-----BEGIN CERTIFICATE-----
     ...
diff --git a/doc/ci/environments/deployment_safety.md b/doc/ci/environments/deployment_safety.md
index 1b34b520007..78f30b29e06 100644
--- a/doc/ci/environments/deployment_safety.md
+++ b/doc/ci/environments/deployment_safety.md
@@ -60,7 +60,7 @@ The improved pipeline flow **after** using the resource group:
 1. `deploy` job in Pipeline-A finishes.
 1. `deploy` job in Pipeline-B starts running.
 
-For more information, see [`resource_group` keyword in `.gitlab-ci.yml`](../yaml/index.md#resource_group).
+For more information, see [Resource Group documentation](../resource_groups/index.md).
 
 ## Skip outdated deployment jobs
 
diff --git a/doc/ci/environments/img/environments_list.png b/doc/ci/environments/img/environments_list.png
deleted file mode 100644
index 6ddfd858ab6..00000000000
--- a/doc/ci/environments/img/environments_list.png
+++ /dev/null
diff --git a/doc/ci/environments/img/environments_list_v14_3.png b/doc/ci/environments/img/environments_list_v14_3.png
new file mode 100644
index 00000000000..8fdb85338e7
--- /dev/null
+++ b/doc/ci/environments/img/environments_list_v14_3.png
diff --git a/doc/ci/environments/img/environments_terminal_button_on_index_v13_10.png b/doc/ci/environments/img/environments_terminal_button_on_index_v13_10.png
deleted file mode 100644
index 4a9a4e65d00..00000000000
--- a/doc/ci/environments/img/environments_terminal_button_on_index_v13_10.png
+++ /dev/null
diff --git a/doc/ci/environments/img/environments_terminal_button_on_index_v14_3.png b/doc/ci/environments/img/environments_terminal_button_on_index_v14_3.png
new file mode 100644
index 00000000000..d1faf489277
--- /dev/null
+++ b/doc/ci/environments/img/environments_terminal_button_on_index_v14_3.png
diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md
index 6bac004fcdf..ca81ad30317 100644
--- a/doc/ci/environments/index.md
+++ b/doc/ci/environments/index.md
@@ -19,7 +19,7 @@ GitLab:
 - Tracks your deployments, so you always know what is deployed on your
   servers.
 
-If you have a deployment service like [Kubernetes](../../user/project/clusters/index.md)
+If you have a deployment service like [Kubernetes](../../user/infrastructure/clusters/index.md)
 associated with your project, you can use it to assist with your deployments.
 You can even access a [web terminal](#web-terminals) for your environment from within GitLab.
 
@@ -35,7 +35,7 @@ To view a list of environments and deployments:
 1. On the left sidebar, select **Deployments > Environments**.
    The environments are displayed.
 
-   ![Environments list](img/environments_list.png)
+   ![Environments list](img/environments_list_v14_3.png)
 
 1. To view a list of deployments for an environment, select the environment name,
    for example, `staging`.
@@ -175,13 +175,13 @@ You can find the play button in the pipelines, environments, deployments, and jo
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) in GitLab 12.6.
 
-If you are deploying to a [Kubernetes cluster](../../user/project/clusters/index.md)
+If you are deploying to a [Kubernetes cluster](../../user/infrastructure/clusters/index.md)
 associated with your project, you can configure these deployments from your
 `.gitlab-ci.yml` file.
 
 NOTE:
 Kubernetes configuration isn't supported for Kubernetes clusters that are
-[managed by GitLab](../../user/project/clusters/index.md#gitlab-managed-clusters).
+[managed by GitLab](../../user/project/clusters/gitlab_managed_clusters.md).
 To follow progress on support for GitLab-managed clusters, see the
 [relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/38054).
 
@@ -634,7 +634,7 @@ Metric charts can be embedded in GitLab Flavored Markdown. See [Embedding Metric
 ### Web terminals
 
 If you deploy to your environments with the help of a deployment service (for example,
-the [Kubernetes integration](../../user/project/clusters/index.md)), GitLab can open
+the [Kubernetes integration](../../user/infrastructure/clusters/index.md)), GitLab can open
 a terminal session to your environment. You can then debug issues without leaving your web browser.
 
 The Web terminal is a container-based deployment, which often lack basic tools (like an editor),
@@ -646,9 +646,9 @@ Web terminals:
 - Are available to project Maintainers and Owners only.
 - Must [be enabled](../../administration/integration/terminal.md).
 
-In the UI, you can view the Web terminal by selecting a **Terminal** button:
+In the UI, you can view the Web terminal by selecting **Terminal** from the actions menu:
 
-![Terminal button on environment index](img/environments_terminal_button_on_index_v13_10.png)
+![Terminal button on environment index](img/environments_terminal_button_on_index_v14_3.png)
 
 You can also access the terminal button from the page for a specific environment:
 
@@ -816,3 +816,62 @@ To ensure the `action: stop` can always run when needed, you can:
       action: stop
     when: manual
   ```
+
+### A deployment job failed with "This job could not be executed because it would create an environment with an invalid parameter" error
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/21182) in GitLab 14.4.
+
+FLAG:
+On self-managed GitLab, by default this bug fix is not available. To make it available per project or for your entire instance, ask an administrator to [enable the `surface_environment_creation_failure` flag](../../administration/feature_flags.md). On GitLab.com, this bug fix is not available, but will be rolled out shortly.
+
+If your project is configured to [create a dynamic environment](#create-a-dynamic-environment),
+you might encounter this error because the dynamically generated parameter can't be used for creating an environment.
+
+For example, your project has the following `.gitlab-ci.yml`:
+
+```yaml
+deploy:
+  script: echo
+  environment: production/$ENVIRONMENT
+```
+
+Since `$ENVIRONMENT` variable does not exist in the pipeline, GitLab tries to
+create an environment with a name `production/`, which is invalid in
+[the environment name constraint](../yaml/index.md).
+
+To fix this, use one of the following solutions:
+
+- Remove `environment` keyword from the deployment job. GitLab has already been
+  ignoring the invalid keyword, therefore your deployment pipelines stay intact
+  even after the keyword removal.
+- Ensure the variable exists in the pipeline. Please note that there is
+  [a limitation on supported variables](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
+
+#### If you get this error on Review Apps
+
+For example, if you have the following in your `.gitlab-ci.yml`:
+
+```yaml
+review:
+  script: deploy review app
+  environment: review/$CI_COMMIT_REF_NAME
+```
+
+When you create a new merge request with a branch name `bug-fix!`,
+the `review` job tries to create an environment with `review/bug-fix!`.
+However, the `!` is an invalid character for environments, so the
+deployment job fails since it was about to run without an environment.
+
+To fix this, use one of the following solutions:
+
+- Re-create your feature branch without the invalid characters,
+  such as `bug-fix`.
+- Replace the `CI_COMMIT_REF_NAME`
+  [predefined variable](../variables/predefined_variables.md) with
+  `CI_COMMIT_REF_SLUG` which strips any invalid characters:
+
+  ```yaml
+  review:
+    script: deploy review app
+    environment: review/$CI_COMMIT_REF_SLUG
+  ```
diff --git a/doc/ci/environments/protected_environments.md b/doc/ci/environments/protected_environments.md
index b31e51b35fc..47f93b03136 100644
--- a/doc/ci/environments/protected_environments.md
+++ b/doc/ci/environments/protected_environments.md
@@ -2,26 +2,22 @@
 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
-type: concepts, howto
 ---
 
 # Protected environments **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6303) in GitLab 11.3.
+[Environments](../environments/index.md) can be used for both testing and
+production reasons.
 
-[Environments](../environments/index.md) can be used for different reasons:
+Because deploy jobs can be raised by different users with different roles, it's
+important to be able to protect specific environments from the effects of
+unauthorized users.
 
-- Some of them are just for testing.
-- Others are for production.
-
-Since deploy jobs can be raised by different users with different roles, it is important that
-specific environments are "protected" to prevent unauthorized people from affecting them.
-
-By default, a protected environment does one thing: it ensures that only people
-with the right privileges can deploy to it, thus keeping it safe.
+By default, a protected environment ensures that only people with the
+appropriate privileges can deploy to it, keeping the environment safe.
 
 NOTE:
-A GitLab admin is always allowed to use environments, even if they are protected.
+GitLab administrators can use all environments, including protected environments.
 
 To protect, update, or unprotect an environment, you need to have at least the
 [Maintainer role](../../user/permissions.md).
@@ -157,9 +153,9 @@ For more information, see [Deployment safety](deployment_safety.md).
 
 ## Group-level protected environments
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215888) in GitLab 14.0. [Deployed behind the `group_level_protected_environments` flag](../../administration/feature_flags.md), disabled by default.
-> - [Feature flag `group_level_protected_environments`](https://gitlab.com/gitlab-org/gitlab/-/issues/331085) removed in GitLab 14.3.
-> - [Generally Available](https://gitlab.com/gitlab-org/gitlab/-/issues/331085) on GitLab and on GitLab.com in 14.3.
+> - Introduced in GitLab 14.0 [with a flag](https://gitlab.com/gitlab-org/gitlab/-/issues/215888) named `group_level_protected_environments`. Disabled by default.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/331085) in GitLab 14.3.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/331085) in GitLab 14.3.
 
 Typically, large enterprise organizations have an explicit permission boundary
 between [developers and operators](https://about.gitlab.com/topics/devops/).
@@ -210,8 +206,8 @@ configured:
   (or above) to the top-level group. They can maintain CI/CD configurations for
   the higher environments (such as production) in the group-level settings page,
   which includes group-level protected environments,
-  [group-level runners](../runners/runners_scope.md#group-runners),
-  [group-level clusters](../../user/group/clusters/index.md), etc. Those
+  [group-level runners](../runners/runners_scope.md#group-runners), and
+  [group-level clusters](../../user/group/clusters/index.md). Those
   configurations are inherited to the child projects as read-only entries.
   This ensures that only operators can configure the organization-wide
   deployment ruleset.
@@ -246,11 +242,11 @@ To protect a group-level environment:
 1. Make sure your environments have the correct
    [`deployment_tier`](index.md#deployment-tier-of-environments) defined in
    `.gitlab-ci.yml`.
-1. Configure the group-level protected environments via the
+1. Configure the group-level protected environments by using the
    [REST API](../../api/group_protected_environments.md).
 
 NOTE:
-Configuration [via the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/325249)
+Configuration [with the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/325249)
 is scheduled for a later release.
 
 <!-- ## Troubleshooting
diff --git a/doc/ci/examples/README.md b/doc/ci/examples/README.md
deleted file mode 100644
index 0e6c2f63f9e..00000000000
--- a/doc/ci/examples/README.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2021-09-28'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after 2021-09-28. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/examples/deployment/README.md b/doc/ci/examples/deployment/README.md
deleted file mode 100644
index 0e6c2f63f9e..00000000000
--- a/doc/ci/examples/deployment/README.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2021-09-28'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after 2021-09-28. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md
index 6817c7cac8e..aa4055c00ea 100644
--- a/doc/ci/examples/deployment/composer-npm-deploy.md
+++ b/doc/ci/examples/deployment/composer-npm-deploy.md
@@ -7,7 +7,7 @@ type: tutorial
 
 # Running Composer and npm scripts with deployment via SCP in GitLab CI/CD **(FREE)**
 
-This guide covers the building of dependencies of a PHP project while compiling assets via an npm script using [GitLab CI/CD](../../README.md).
+This guide covers the building of dependencies of a PHP project while compiling assets via an npm script using [GitLab CI/CD](../../index.md).
 
 While it is possible to create your own image with custom PHP and Node.js versions, for brevity we use an existing [Docker image](https://hub.docker.com/r/tetraweb/php/) that contains both PHP and Node.js installed.
 
diff --git a/doc/ci/examples/deployment/index.md b/doc/ci/examples/deployment/index.md
index 14fb77dc49f..b083dbb8177 100644
--- a/doc/ci/examples/deployment/index.md
+++ b/doc/ci/examples/deployment/index.md
@@ -56,7 +56,7 @@ To use different provider take a look at long list of [Supported Providers](http
 ## Using Dpl with Docker
 
 In most cases, you configured [GitLab Runner](https://docs.gitlab.com/runner/) to use your server's shell commands.
-This means that all commands are run in the context of local user (e.g. `gitlab_runner` or `gitlab_ci_multi_runner`).
+This means that all commands are run in the context of local user (for example `gitlab_runner` or `gitlab_ci_multi_runner`).
 It also means that most probably in your Docker container you don't have the Ruby runtime installed.
 You must install it:
 
@@ -69,7 +69,7 @@ staging:
     - gem install dpl
     - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
   only:
-    - master
+    - main
 ```
 
 The first line `apt-get update -yq` updates the list of available packages,
@@ -81,7 +81,7 @@ The above example is valid for all Debian-compatible systems.
 It's pretty common in the development workflow to have staging (development) and
 production environments
 
-Let's consider the following example: we would like to deploy the `master`
+Let's consider the following example: we would like to deploy the `main`
 branch to `staging` and all tags to the `production` environment.
 The final `.gitlab-ci.yml` for that setup would look like this:
 
@@ -92,7 +92,7 @@ staging:
     - gem install dpl
     - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
   only:
-    - master
+    - main
 
 production:
   stage: deploy
@@ -105,7 +105,7 @@ production:
 
 We created two deploy jobs that are executed on different events:
 
-- `staging`: Executed for all commits pushed to the `master` branch
+- `staging`: Executed for all commits pushed to the `main` branch
 - `production`: Executed for all pushed tags
 
 We also use two secure variables:
diff --git a/doc/ci/examples/end_to_end_testing_webdriverio/index.md b/doc/ci/examples/end_to_end_testing_webdriverio/index.md
index 06074d6edc2..a9794afaf10 100644
--- a/doc/ci/examples/end_to_end_testing_webdriverio/index.md
+++ b/doc/ci/examples/end_to_end_testing_webdriverio/index.md
@@ -33,7 +33,7 @@ to write such end-to-end tests, and how to set up GitLab CI/CD to automatically
 against your new code, on a branch-by-branch basis. For the scope of this article, we will walk you
 through the process of setting up GitLab CI/CD for end-to-end testing JavaScript-based applications
 with WebdriverIO, but the general strategy should carry over to other languages.
-We assume you are familiar with GitLab, [GitLab CI/CD](../../README.md), [Review Apps](../../review_apps/index.md), and running your app locally, e.g., on `localhost:8000`.
+We assume you are familiar with GitLab, [GitLab CI/CD](../../index.md), [Review Apps](../../review_apps/index.md), and running your app locally, e.g., on `localhost:8000`.
 
 ## What to test
 
@@ -150,8 +150,8 @@ need to do for this:
 1. Update our WebdriverIO configuration to use those browsers to visit the review apps.
 
 For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/index.md#stages)
-`confidence-check` that is executed _after_ the stage that deploys the review app. It uses the `node:latest` [Docker
-image](../../docker/using_docker_images.md). However, WebdriverIO fires up actual browsers
+`confidence-check` that is executed _after_ the stage that deploys the review app. It uses the `node:latest`
+[Docker image](../../docker/using_docker_images.md). However, WebdriverIO fires up actual browsers
 to interact with your application, so we need to install and run them.
 Furthermore, WebdriverIO uses Selenium as a common interface to control different browsers,
 so we need to install and run Selenium as well. Luckily, the Selenium project provides the Docker images
diff --git a/doc/ci/examples/index.md b/doc/ci/examples/index.md
index 2c2c6ecd30f..0fc7b06a584 100644
--- a/doc/ci/examples/index.md
+++ b/doc/ci/examples/index.md
@@ -9,7 +9,7 @@ type: index
 # GitLab CI/CD Examples **(FREE)**
 
 This page contains links to a variety of examples that can help you understand how to
-implement [GitLab CI/CD](../README.md) for your specific use case.
+implement [GitLab CI/CD](../index.md) for your specific use case.
 
 Examples are available in several forms. As a collection of:
 
diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
index c511839b3e4..e2e12235eba 100644
--- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
+++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
@@ -17,7 +17,7 @@ date: 2017-08-31
 
 GitLab features our applications with Continuous Integration, and it is possible to easily deploy the new code changes to the production server whenever we want.
 
-In this tutorial, we'll show you how to initialize a [Laravel](https://laravel.com) application and set up our [Envoy](https://laravel.com/docs/master/envoy) tasks, then we'll jump into see how to test and deploy it with [GitLab CI/CD](../README.md) via [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/).
+In this tutorial, we'll show you how to initialize a [Laravel](https://laravel.com) application and set up our [Envoy](https://laravel.com/docs/master/envoy) tasks, then we'll jump into see how to test and deploy it with [GitLab CI/CD](../index.md) via [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/).
 
 We assume you have a basic experience with Laravel, Linux servers,
 and you know how to use GitLab.
@@ -394,7 +394,7 @@ We have our app ready on GitLab, and we also can deploy it manually.
 But let's take a step forward to do it automatically with [Continuous Delivery](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-delivery) method.
 We need to check every commit with a set of automated tests to become aware of issues at the earliest, and then, we can deploy to the target environment if we are happy with the result of the tests.
 
-[GitLab CI/CD](../../README.md) allows us to use [Docker](https://www.docker.com) engine to handle the process of testing and deploying our app.
+[GitLab CI/CD](../../index.md) allows us to use [Docker](https://www.docker.com) engine to handle the process of testing and deploying our app.
 In case you're not familiar with Docker, refer to [Set up automated builds](https://docs.docker.com/get-started/).
 
 To be able to build, test, and deploy our app with GitLab CI/CD, we need to prepare our work environment.
diff --git a/doc/ci/index.md b/doc/ci/index.md
index 87b259af62a..2f18bd28642 100644
--- a/doc/ci/index.md
+++ b/doc/ci/index.md
@@ -32,10 +32,10 @@ For a complete overview of these methodologies and GitLab CI/CD,
 read the [Introduction to CI/CD with GitLab](introduction/index.md).
 
 <div class="video-fallback">
-  Video demonstration of GitLab CI/CD: <a href="https://www.youtube.com/watch?v=1iXFbchozdY">Demo: CI/CD with GitLab</a>.
+  Video demonstration of continuous integration with GitLab CI/CD: <a href="https://www.youtube.com/watch?v=ljth1Q5oJoo">Continuous Integration with GitLab (overview demo)</a>.
 </div>
 <figure class="video-container">
-  <iframe src="https://www.youtube.com/embed/1iXFbchozdY" frameborder="0" allowfullscreen="true"> </iframe>
+  <iframe src="https://www.youtube.com/embed/ljth1Q5oJoo" frameborder="0" allowfullscreen="true"> </iframe>
 </figure>
 
 ## GitLab CI/CD concepts
@@ -46,7 +46,7 @@ GitLab CI/CD uses a number of concepts to describe and run your build and deploy
 |:--------------------------------------------------------|:-------------------------------------------------------------------------------|
 | [Pipelines](pipelines/index.md)                         | Structure your CI/CD process through pipelines.                                |
 | [CI/CD variables](variables/index.md)                  | Reuse values based on a variable/value key pair.                               |
-| [Environments](environments/index.md)                   | Deploy your application to different environments (e.g., staging, production). |
+| [Environments](environments/index.md)                   | Deploy your application to different environments (for example, staging, production). |
 | [Job artifacts](pipelines/job_artifacts.md)             | Output, use, and reuse job artifacts.                                          |
 | [Cache dependencies](caching/index.md)                  | Cache your dependencies for a faster execution.                                |
 | [GitLab Runner](https://docs.gitlab.com/runner/)        | Configure your own runners to execute your scripts.                            |
@@ -65,7 +65,7 @@ GitLab CI/CD supports numerous configuration options:
 | [SSH keys for CI/CD](ssh_keys/index.md)                                                 | Using SSH keys in your CI pipelines.                                                      |
 | [Pipeline triggers](triggers/index.md)                                                  | Trigger pipelines through the API.                                                        |
 | [Pipelines for Merge Requests](pipelines/merge_request_pipelines.md)                    | Design a pipeline structure for running a pipeline in merge requests.                     |
-| [Integrate with Kubernetes clusters](../user/project/clusters/index.md)                 | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. |
+| [Integrate with Kubernetes clusters](../user/infrastructure/clusters/index.md)                 | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. |
 | [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories.                                   |
 | [`.gitlab-ci.yml` full reference](yaml/index.md)                                        | All the attributes you can use with GitLab CI/CD.                                         |
 
@@ -97,7 +97,7 @@ GitLab CI/CD features, grouped by DevOps stage, include:
 | [Building Docker images](docker/using_docker_build.md)                                          | Maintain Docker-based projects using GitLab CI/CD.                                                                             |
 | [Canary Deployments](../user/project/canary_deployments.md)                                     | Ship features to only a portion of your pods and let a percentage of your user base to visit the temporarily deployed feature. |
 | [Deploy boards](../user/project/deploy_boards.md)                                               | Check the current health and status of each CI/CD environment running on Kubernetes.                                           |
-| [Feature Flags](../operations/feature_flags.md) **(PREMIUM)**                                   | Deploy your features behind Feature Flags.                                                                                     |
+| [Feature Flags](../operations/feature_flags.md)                                                 | Deploy your features behind Feature Flags.                                                                                     |
 | [GitLab Pages](../user/project/pages/index.md)                                                  | Deploy static websites.                                                                                                        |
 | [GitLab Releases](../user/project/releases/index.md)                                            | Add release notes to Git tags.                                                                                                 |
 | [Review Apps](review_apps/index.md)                                                             | Configure GitLab CI/CD to preview code changes.                                                                                |
@@ -111,7 +111,7 @@ GitLab CI/CD features, grouped by DevOps stage, include:
 
 ## GitLab CI/CD examples
 
-See the [CI/CD examples](examples/README.md) page for example project code and tutorials for
+See the [CI/CD examples](examples/index.md) page for example project code and tutorials for
 using GitLab CI/CD with various:
 
 - App frameworks
diff --git a/doc/ci/jobs/ci_job_token.md b/doc/ci/jobs/ci_job_token.md
index 70c22d566e5..308f38b22b7 100644
--- a/doc/ci/jobs/ci_job_token.md
+++ b/doc/ci/jobs/ci_job_token.md
@@ -12,9 +12,8 @@ When a pipeline job is about to run, GitLab generates a unique token and injects
 You can use a GitLab CI/CD job token to authenticate with specific API endpoints:
 
 - Packages:
-  - [Package Registry](../../user/packages/package_registry/index.md). To push to the
-    Package Registry, you can use [deploy tokens](../../user/project/deploy_tokens/index.md).
-  - [Container Registry](../../user/packages/container_registry/index.md)
+  - [Package Registry](../../user/packages/package_registry/index.md#use-gitlab-cicd-to-build-packages).
+  - [Container Registry](../../user/packages/container_registry/index.md#build-and-push-by-using-gitlab-cicd)
     (the `$CI_REGISTRY_PASSWORD` is `$CI_JOB_TOKEN`).
   - [Container Registry API](../../api/container_registry.md)
     (scoped to the job's project, when the `ci_job_token_scope` feature flag is enabled).
@@ -24,8 +23,8 @@ You can use a GitLab CI/CD job token to authenticate with specific API endpoints
 - [Release creation](../../api/releases/index.md#create-a-release).
 - [Terraform plan](../../user/infrastructure/index.md).
 
-The token has the same permissions to access the API as the user that triggers the
-pipeline. Therefore, this user must be assigned to [a role that has the required privileges](../../user/permissions.md#gitlab-cicd-permissions).
+The token has the same permissions to access the API as the user that executes the
+job. Therefore, this user must be assigned to [a role that has the required privileges](../../user/permissions.md#gitlab-cicd-permissions).
 
 The token is valid only while the pipeline job runs. After the job finishes, you can't
 use the token anymore.
@@ -60,20 +59,20 @@ tries to steal tokens from other jobs.
 
 ## Limit GitLab CI/CD job token access
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/328553) in GitLab 14.1.
-> - [Deployed behind a feature flag](../../user/feature_flags.md), disabled by default.
-> - Disabled on GitLab.com.
-> - Not recommended for production use.
-> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-ci-job-token-scope-limit). **(FREE SELF)**
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/328553) in GitLab 14.1. [Deployed behind the `:ci_scoped_job_token` feature flag](../../user/feature_flags.md), disabled by default.
+> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/332272) in GitLab 14.4.
 
-This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
-Refer to this feature's version history for more details.
+FLAG:
+On self-managed GitLab, by default this feature is available. To hide the feature,
+ask an administrator to [disable the `ci_scoped_job_token` flag](../../administration/feature_flags.md).
+On GitLab.com, this feature is available.
 
 You can limit the access scope of a project's CI/CD job token to increase the
 job token's security. A job token might give extra permissions that aren't necessary
-to access specific private resources. Limiting the job token access scope reduces the risk of a leaked
-token being used to access private data that the user associated to the job can access.
+to access specific private resources.
+If a job token is leaked it could potentially be used to access data that is private
+to the job token's user. By limiting the job token access scope, private data cannot
+be accessed unless projects are explicitly authorized.
 
 Control the job token access scope with an allowlist of other projects authorized
 to be accessed by authenticating with the current project's job token. By default
@@ -87,10 +86,10 @@ setting at all times, and configure the allowlist for cross-project access if ne
 For example, when the setting is enabled, jobs in a pipeline in project `A` have
 a `CI_JOB_TOKEN` scope limited to project `A`. If the job needs to use the token
 to make an API request to a private project `B`, then `B` must be added to the allowlist for `A`.
-If project `B` is public or internal, it doesn't need to be added to the allowlist.
+If project `B` is public or internal, it's not required to be added to the allowlist.
 The job token scope is only for controlling access to private projects.
 
-To enable and configure the job token scope limit:
+### Configure the job token scope limit
 
 1. On the top bar, select **Menu > Projects** and find your project.
 1. On the left sidebar, select **Settings > CI/CD**.
@@ -99,31 +98,9 @@ To enable and configure the job token scope limit:
 1. (Optional) Add existing projects to the token's access scope. The user adding a
    project must have the [maintainer role](../../user/permissions.md) in both projects.
 
-If the job token scope limit is disabled, the token can potentially be used to authenticate
-API requests to all projects accessible to the user that triggered the job.
-
 There is [a proposal](https://gitlab.com/groups/gitlab-org/-/epics/3559) to improve
 the feature with more strategic control of the access permissions.
 
-### Enable or disable CI job token scope limit **(FREE SELF)**
-
-The GitLab CI/CD job token access scope limit is under development and not ready for production
-use. It is deployed behind a feature flag that is **disabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md)
-can enable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:ci_scoped_job_token)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:ci_scoped_job_token)
-```
-
 ## Trigger a multi-project pipeline by using a CI job token
 
 > `CI_JOB_TOKEN` for multi-project pipelines was [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) from GitLab Premium to GitLab Free in 12.4.
@@ -163,3 +140,50 @@ build_submodule:
 ```
 
 Read more about the [jobs artifacts API](../../api/job_artifacts.md#download-the-artifacts-archive).
+
+## Troubleshooting
+
+CI job token failures are usually shown as responses like `404 Not Found` or similar:
+
+- Unauthorized Git clone:
+
+  ```plaintext
+  $ git clone https://gitlab-ci-token:$CI_JOB_TOKEN@gitlab.com/fabiopitino/test2.git
+
+  Cloning into 'test2'...
+  remote: The project you were looking for could not be found or you don't have permission to view it.
+  fatal: repository 'https://gitlab-ci-token:[MASKED]@gitlab.com/<namespace>/<project>.git/' not found
+  ```
+
+- Unauthorized package download:
+
+  ```plaintext
+  $ wget --header="JOB-TOKEN: $CI_JOB_TOKEN" ${CI_API_V4_URL}/projects/1234/packages/generic/my_package/0.0.1/file.txt
+
+  --2021-09-23 11:00:13--  https://gitlab.com/api/v4/projects/1234/packages/generic/my_package/0.0.1/file.txt
+  Resolving gitlab.com (gitlab.com)... 172.65.251.78, 2606:4700:90:0:f22e:fbec:5bed:a9b9
+  Connecting to gitlab.com (gitlab.com)|172.65.251.78|:443... connected.
+  HTTP request sent, awaiting response... 404 Not Found
+  2021-09-23 11:00:13 ERROR 404: Not Found.
+  ```
+
+- Unauthorized API request:
+
+  ```plaintext
+  $ curl --verbose --request POST --form "token=$CI_JOB_TOKEN" --form ref=master "https://gitlab.com/api/v4/projects/1234/trigger/pipeline"
+
+  < HTTP/2 404
+  < date: Thu, 23 Sep 2021 11:00:12 GMT
+  {"message":"404 Not Found"}
+  < content-type: application/json
+  ```
+
+While troubleshooting CI/CD job token authentication issues, be aware that:
+
+- When the [CI/CD job token limit](#limit-gitlab-cicd-job-token-access) is enabled,
+  and the job token is being used to access a different project:
+  - The user that executes the job must be a member of the project that is being accessed.
+  - The user must have the [permissions](../../user/permissions.md) to perform the action.
+  - The target project must be [allowlisted for the job token scope limit](#configure-the-job-token-scope-limit).
+- The CI job token becomes invalid if the job is no longer running, has been erased,
+  or if the project is in the process of being deleted.
diff --git a/doc/ci/jobs/index.md b/doc/ci/jobs/index.md
index 54704d5574b..cb3b11ebf99 100644
--- a/doc/ci/jobs/index.md
+++ b/doc/ci/jobs/index.md
@@ -45,8 +45,6 @@ Clicking an individual job shows you its job log, and allows you to:
 
 ## See why a job failed
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17782) in GitLab 10.7.
-
 When a pipeline fails or is allowed to fail, there are several places where you
 can find the reason:
 
@@ -58,8 +56,7 @@ In each place, if you hover over the failed job you can see the reason it failed
 
 ![Pipeline detail](img/job_failure_reason.png)
 
-In [GitLab 10.8 and later](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17814),
-you can also see the reason it failed on the Job detail page.
+You can also see the reason it failed on the Job detail page.
 
 ## The order of jobs in a pipeline
 
@@ -87,8 +84,6 @@ For example:
 
 ## Group jobs in a pipeline
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6242) in GitLab 8.12.
-
 If you have many similar jobs, your [pipeline graph](../pipelines/index.md#visualize-pipelines) becomes long and hard
 to read.
 
@@ -164,8 +159,6 @@ for a single run of the manual job.
 
 ## Delay a job
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21767) in GitLab 11.4.
-
 When you do not want to run a job immediately, you can use the [`when:delayed`](../jobs/job_control.md#run-a-job-after-a-delay) keyword to
 delay a job's execution for a certain period.
 
diff --git a/doc/ci/lint.md b/doc/ci/lint.md
index e01bd6b79ff..45152e5a0df 100644
--- a/doc/ci/lint.md
+++ b/doc/ci/lint.md
@@ -4,7 +4,7 @@ group: Pipeline Authoring
 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
 ---
 
-# Validate `.gitlab-ci.yml` syntax with the CI Lint tool
+# Validate `.gitlab-ci.yml` syntax with the CI Lint tool **(FREE)**
 
 If you want to test the validity of your GitLab CI/CD configuration before committing
 the changes, you can use the CI Lint tool. This tool checks for syntax and logical
diff --git a/doc/ci/merge_request_pipelines/index.md b/doc/ci/merge_request_pipelines/index.md
deleted file mode 100644
index 13f4ca428c6..00000000000
--- a/doc/ci/merge_request_pipelines/index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: '../pipelines/merge_request_pipelines.md'
-remove_date: '2021-09-29'
----
-
-This document was moved to [another location](../pipelines/merge_request_pipelines.md).
-
-<!-- This redirect file can be deleted after 2021-09-29. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
deleted file mode 100644
index 5b68c4ca931..00000000000
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: '../../pipelines/pipelines_for_merged_results.md'
-remove_date: '2021-09-29'
----
-
-This document was moved to [another location](../../pipelines/pipelines_for_merged_results.md).
-
-<!-- This redirect file can be deleted after 2021-09-29. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
deleted file mode 100644
index c8e8dffbdcd..00000000000
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: '../../../pipelines/merge_trains.md'
-remove_date: '2021-09-29'
----
-
-This document was moved to [another location](../../../pipelines/merge_trains.md).
-
-<!-- This redirect file can be deleted after 2021-09-29. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/metrics_reports.md b/doc/ci/metrics_reports.md
index 9a220121f54..5343af16489 100644
--- a/doc/ci/metrics_reports.md
+++ b/doc/ci/metrics_reports.md
@@ -7,7 +7,7 @@ type: reference
 
 # Metrics Reports **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9788) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10. Requires GitLab Runner 11.10 and above.
+> [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](../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.
 
diff --git a/doc/ci/migration/jenkins.md b/doc/ci/migration/jenkins.md
index 925dff8751c..c2c06375d7b 100644
--- a/doc/ci/migration/jenkins.md
+++ b/doc/ci/migration/jenkins.md
@@ -42,8 +42,8 @@ can be a great resource.
 ## Manage organizational transition
 
 An important part of transitioning from Jenkins to GitLab is the cultural and organizational
-changes that comes with the move, and successfully managing them. There are a few
-things we have found that helps this:
+changes that come with the move, and successfully managing them. There are a few
+things we have found that help this:
 
 - Setting and communicating a clear vision of what your migration goals are helps
   your users understand why the effort is worth it. The value is clear when
diff --git a/doc/ci/multi_project_pipelines.md b/doc/ci/multi_project_pipelines.md
deleted file mode 100644
index 93e04bf8a0e..00000000000
--- a/doc/ci/multi_project_pipelines.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: 'pipelines/multi_project_pipelines.md'
-remove_date: '2021-09-29'
----
-
-This document was moved to [another location](pipelines/multi_project_pipelines.md).
-
-<!-- This redirect file can be deleted after 2021-09-29. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/parent_child_pipelines.md b/doc/ci/parent_child_pipelines.md
deleted file mode 100644
index f2edc263397..00000000000
--- a/doc/ci/parent_child_pipelines.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: 'pipelines/parent_child_pipelines.md'
-remove_date: '2021-09-29'
----
-
-This document was moved to [another location](pipelines/parent_child_pipelines.md).
-
-<!-- This redirect file can be deleted after 2021-09-29. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/pipelines/img/multi_project_pipeline_graph.png b/doc/ci/pipelines/img/multi_project_pipeline_graph.png
deleted file mode 100644
index 723a455cb4a..00000000000
--- a/doc/ci/pipelines/img/multi_project_pipeline_graph.png
+++ /dev/null
diff --git a/doc/ci/pipelines/img/multi_project_pipeline_graph_v14_3.png b/doc/ci/pipelines/img/multi_project_pipeline_graph_v14_3.png
new file mode 100644
index 00000000000..aadf8bb0979
--- /dev/null
+++ b/doc/ci/pipelines/img/multi_project_pipeline_graph_v14_3.png
diff --git a/doc/ci/pipelines/img/parent_pipeline_graph_expanded_v12_6.png b/doc/ci/pipelines/img/parent_pipeline_graph_expanded_v12_6.png
deleted file mode 100644
index db18cc201fc..00000000000
--- a/doc/ci/pipelines/img/parent_pipeline_graph_expanded_v12_6.png
+++ /dev/null
diff --git a/doc/ci/pipelines/img/parent_pipeline_graph_expanded_v14_3.png b/doc/ci/pipelines/img/parent_pipeline_graph_expanded_v14_3.png
new file mode 100644
index 00000000000..206e4eeec05
--- /dev/null
+++ b/doc/ci/pipelines/img/parent_pipeline_graph_expanded_v14_3.png
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index 1eacc799636..69e974406e2 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -38,7 +38,7 @@ A typical pipeline might consist of four stages, executed in the following order
 - A `production` stage, with a job called `deploy-to-prod`.
 
 NOTE:
-If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/repository_mirroring.md#pull-from-a-remote-repository),
+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**.
 
@@ -148,7 +148,7 @@ The pipeline now executes the jobs as configured.
 
 #### Prefill variables in manual pipelines
 
-> [Introduced in](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) GitLab 13.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30101) in GitLab 13.7.
 
 You can use the [`value` and `description`](../yaml/index.md#prefill-variables-in-manual-pipelines)
 keywords to define
@@ -339,7 +339,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 c6b6f61ef11..7ecee5508ef 100644
--- a/doc/ci/pipelines/job_artifacts.md
+++ b/doc/ci/pipelines/job_artifacts.md
@@ -8,7 +8,7 @@ type: reference, howto
 
 # Job artifacts **(FREE)**
 
-> Introduced in [GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16675), artifacts in internal and private projects can be previewed when [GitLab Pages access control](../../administration/pages/index.md#access-control) is enabled.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16675) in GitLab 12.4, artifacts in internal and private projects can be previewed when [GitLab Pages access control](../../administration/pages/index.md#access-control) is enabled.
 
 Jobs can output an archive of files and directories. This output is known as a job artifact.
 
@@ -111,7 +111,7 @@ the artifact.
 
 ## How searching for job artifacts works
 
-In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/201784) and later, artifacts
+In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201784), artifacts
 for [parent and child pipelines](parent_child_pipelines.md) are searched in hierarchical
 order from parent to child. For example, if both parent and child pipelines have a
 job with the same name, the job artifact from the parent pipeline is returned.
diff --git a/doc/ci/pipelines/merge_request_pipelines.md b/doc/ci/pipelines/merge_request_pipelines.md
index b3dfe8753c7..5b40744aa79 100644
--- a/doc/ci/pipelines/merge_request_pipelines.md
+++ b/doc/ci/pipelines/merge_request_pipelines.md
@@ -198,7 +198,7 @@ which helps you get your starting configuration correct.
 If you are seeing two pipelines when using `only/except`, please see the caveats
 related to using `only/except` above (or, consider moving to `rules`).
 
-In [GitLab 13.7](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) and later,
+In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201845),
 you can add `workflow:rules` to [switch from branch pipelines to merge request pipelines](../yaml/index.md#switch-between-branch-pipelines-and-merge-request-pipelines).
 After a merge request is open on the branch, the pipeline switches to a merge request pipeline.
 
diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md
index 06c1a6fef44..6074909a887 100644
--- a/doc/ci/pipelines/merge_trains.md
+++ b/doc/ci/pipelines/merge_trains.md
@@ -8,8 +8,8 @@ last_update: 2019-07-03
 
 # Merge trains **(PREMIUM)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9186) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.0.
-> - [Squash and merge](../../user/project/merge_requests/squash_and_merge.md) support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13001) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.6.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9186) in GitLab 12.0.
+> - [Squash and merge](../../user/project/merge_requests/squash_and_merge.md) support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13001) in GitLab 12.6.
 
 For more information about why you might want to use merge trains, read [How merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
 
@@ -59,8 +59,6 @@ to run. If more merge requests are added to the train, they now include the `A`
 changes that are included in the target branch, and the `C` changes that are from
 the merge request already in the train.
 
-Read more about [how merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
-
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 Watch this video for a demonstration on [how parallel execution
 of merge trains can prevent commits from breaking the default
diff --git a/doc/ci/pipelines/multi_project_pipelines.md b/doc/ci/pipelines/multi_project_pipelines.md
index d31ddcf736e..184961f4c95 100644
--- a/doc/ci/pipelines/multi_project_pipelines.md
+++ b/doc/ci/pipelines/multi_project_pipelines.md
@@ -88,7 +88,7 @@ The keywords available for use in trigger jobs are:
 - [`only` and `except`](../yaml/index.md#only--except)
 - [`when`](../yaml/index.md#when) (only with a value of `on_success`, `on_failure`, or `always`)
 - [`extends`](../yaml/index.md#extends)
-- [`needs`](../yaml/index.md#needs)
+- [`needs`](../yaml/index.md#needs), but not [cross project artifact downloads with `needs`](../yaml/index.md#cross-project-artifact-downloads-with-needs)
 
 #### Specify a downstream pipeline branch
 
@@ -112,7 +112,7 @@ Use:
 
 - The `project` keyword to specify the full path to a downstream project.
 - The `branch` keyword to specify the name of a branch in the project specified by `project`.
-  [In GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/10126) and later, variable expansion is
+  In [GitLab 12.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/10126), variable expansion is
   supported.
 
 Pipelines triggered on a protected branch in a downstream project use the [role](../../user/permissions.md)
@@ -290,7 +290,7 @@ When using:
 
 ## Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9045) in GitLab Premium 12.8.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9045) in GitLab 12.8.
 
 You can trigger a pipeline in your project whenever a pipeline finishes for a new
 tag in a different project.
@@ -321,7 +321,7 @@ downstream projects. On self-managed instances, an administrator can change this
 When you configure GitLab CI/CD for your project, you can visualize the stages of your
 [jobs](index.md#configure-a-pipeline) on a [pipeline graph](index.md#visualize-pipelines).
 
-![Multi-project pipeline graph](img/multi_project_pipeline_graph.png)
+![Multi-project pipeline graph](img/multi_project_pipeline_graph_v14_3.png)
 
 In the merge request, on the **Pipelines** tab, multi-project pipeline mini-graphs are displayed.
 They expand and are shown adjacent to each other when hovering (or tapping on touchscreen devices).
diff --git a/doc/ci/pipelines/parent_child_pipelines.md b/doc/ci/pipelines/parent_child_pipelines.md
index 71f778d81b3..e48728a904a 100644
--- a/doc/ci/pipelines/parent_child_pipelines.md
+++ b/doc/ci/pipelines/parent_child_pipelines.md
@@ -23,7 +23,7 @@ Additionally, sometimes the behavior of a pipeline needs to be more dynamic. The
 to choose to start sub-pipelines (or not) is a powerful ability, especially if the
 YAML is dynamically generated.
 
-![Parent pipeline graph expanded](img/parent_pipeline_graph_expanded_v12_6.png)
+![Parent pipeline graph expanded](img/parent_pipeline_graph_expanded_v14_3.png)
 
 Similarly to [multi-project pipelines](multi_project_pipelines.md), a pipeline can trigger a
 set of concurrently running child pipelines, but within the same project:
@@ -72,7 +72,7 @@ microservice_a:
       - template: Security/SAST.gitlab-ci.yml
 ```
 
-In [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/205157) and later,
+In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/205157),
 you can use [`include:file`](../yaml/index.md#includefile) to trigger child pipelines
 with a configuration file in a different project:
 
@@ -169,7 +169,7 @@ runner for testing, the path separator for the trigger job would be `/`. Other C
 configuration for jobs, like scripts, that use the Windows runner would use `\`.
 
 In GitLab 12.9, the child pipeline could fail to be created in certain cases, causing the parent pipeline to fail.
-This is [resolved in GitLab 12.10](https://gitlab.com/gitlab-org/gitlab/-/issues/209070).
+This is [resolved](https://gitlab.com/gitlab-org/gitlab/-/issues/209070) in GitLab 12.10.
 
 ## Nested child pipelines
 
diff --git a/doc/ci/pipelines/pipeline_efficiency.md b/doc/ci/pipelines/pipeline_efficiency.md
index 5c3cdd0633e..94cfeff3acc 100644
--- a/doc/ci/pipelines/pipeline_efficiency.md
+++ b/doc/ci/pipelines/pipeline_efficiency.md
@@ -7,7 +7,7 @@ type: reference
 
 # Pipeline efficiency **(FREE)**
 
-[CI/CD Pipelines](index.md) are the fundamental building blocks for [GitLab CI/CD](../README.md).
+[CI/CD Pipelines](index.md) are the fundamental building blocks for [GitLab CI/CD](../index.md).
 Making pipelines more efficient helps you save developer time, which:
 
 - Speeds up your DevOps processes
diff --git a/doc/ci/pipelines/pipelines_for_merged_results.md b/doc/ci/pipelines/pipelines_for_merged_results.md
index 08d7d119787..2acef9be557 100644
--- a/doc/ci/pipelines/pipelines_for_merged_results.md
+++ b/doc/ci/pipelines/pipelines_for_merged_results.md
@@ -8,7 +8,7 @@ last_update: 2019-07-03
 
 # Pipelines for merged results **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7380) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7380) in GitLab 11.10.
 
 When you submit a merge request, you are requesting to merge changes from a
 source branch into a target branch. By default, the CI pipeline runs jobs
@@ -49,7 +49,7 @@ To enable pipelines for merge results:
 - You must be using [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) 11.9 or later.
 - You must not be using
   [fast forward merges](../../user/project/merge_requests/fast_forward_merge.md) yet.
-  To follow progress, see [#58226](https://gitlab.com/gitlab-org/gitlab/-/issues/26996).
+  To follow progress, see [#26996](https://gitlab.com/gitlab-org/gitlab/-/issues/26996).
 - Your repository must be a GitLab repository, not an
   [external repository](../ci_cd_for_external_repos/index.md).
 
@@ -82,7 +82,7 @@ For more information, read the [documentation on Merge Trains](merge_trains.md).
 
 ## Automatic pipeline cancellation
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12996) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12996) in GitLab 12.3.
 
 GitLab CI/CD can detect the presence of redundant pipelines, and cancels them
 to conserve CI resources.
diff --git a/doc/ci/pipelines/schedules.md b/doc/ci/pipelines/schedules.md
index 9cb600ae551..90494a715ea 100644
--- a/doc/ci/pipelines/schedules.md
+++ b/doc/ci/pipelines/schedules.md
@@ -73,7 +73,7 @@ job:on-schedule:
 
 job:
   rules:
-    - if: $CI_PIPELINE_SOURCE = "push"
+    - if: $CI_PIPELINE_SOURCE == "push"
   script:
     - make build
 ```
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 94d7e317104..e14c1aa621f 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -94,7 +94,7 @@ For more information, see [Deployment safety](../environments/deployment_safety.
 
 ## Specify a custom CI/CD configuration file
 
-> [Support for external `.gitlab-ci.yml` locations](https://gitlab.com/gitlab-org/gitlab/-/issues/14376) introduced in GitLab 12.6.
+> Support for external `.gitlab-ci.yml` locations [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14376) in GitLab 12.6.
 
 GitLab expects to find the CI/CD configuration file (`.gitlab-ci.yml`) in the project's root
 directory. However, you can specify an alternate filename path, including locations outside the project.
@@ -241,7 +241,7 @@ Use this regex for commonly used test tools.
 ### View code coverage history
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209121) the ability to download a `.csv` in GitLab 12.10.
-> - [Graph introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33743) in GitLab 13.1.
+> - Graph [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33743) in GitLab 13.1.
 
 To see the evolution of your project code coverage over time,
 you can view a graph or download a CSV file with this data.
@@ -358,6 +358,29 @@ in your `README.md`:
 ![coverage](https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=coverage)
 ```
 
+#### Test coverage report badge colors and limits
+
+The default colors and limits for the badge are as follows:
+
+- 95 up to and including 100% - good (`#4c1`)
+- 90 up to 95% - acceptable (`#a3c51c`)
+- 75 up to 90% - medium (`#dfb317`)
+- 0 up to 75% - low (`#e05d44`)
+- no coverage - unknown (`#9f9f9f`)
+
+NOTE:
+*Up to* means up to, but not including, the upper bound.
+
+You can overwrite the limits by using the following additional parameters ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/28317) in GitLab 14.4):
+
+- `min_good` (default 95, can use any value between 3 and 100)
+- `min_acceptable` (default 90, can use any value between 2 and min_good-1)
+- `min_medium` (default 75, can use any value between 1 and min_acceptable-1)
+
+If an invalid boundary is set, GitLab automatically adjusts it to be valid. For example,
+if `min_good` is set `80`, and `min_acceptable` is set to `85` (too high), GitLab automatically
+sets `min_acceptable` to `79` (`min_good` - `1`).
+
 ### Badge styles
 
 Pipeline badges can be rendered in different styles by adding the `style=style_name` parameter to the URL. Two styles are available:
diff --git a/doc/ci/quick_start/index.md b/doc/ci/quick_start/index.md
index e2381238318..4006a1c9c3c 100644
--- a/doc/ci/quick_start/index.md
+++ b/doc/ci/quick_start/index.md
@@ -152,7 +152,7 @@ The pipeline starts when the commit is committed.
   - Use the [`rules`](../yaml/index.md#rules) keyword to specify when to run or skip jobs.
     The `only` and `except` legacy keywords are still supported, but can't be used
     with `rules` in the same job.
-  - Keep information across jobs and stages persistent in a pipeline with [`cache`](../yaml/index.md#cache))
+  - Keep information across jobs and stages persistent in a pipeline with [`cache`](../yaml/index.md#cache)
     and [`artifacts`](../yaml/index.md#artifacts). These keywords are ways to store
     dependencies and job output, even when using ephemeral runners for each job.
 - For the complete `.gitlab-ci.yml` syntax, see [the full `.gitlab-ci.yml` reference topic](../yaml/index.md).
diff --git a/doc/ci/resource_groups/index.md b/doc/ci/resource_groups/index.md
new file mode 100644
index 00000000000..7de3643c0d4
--- /dev/null
+++ b/doc/ci/resource_groups/index.md
@@ -0,0 +1,203 @@
+---
+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
+description: Control the job concurrency in GitLab CI/CD
+---
+
+# Resource Group **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15536) in GitLab 12.7.
+
+By default, pipelines in GitLab CI/CD run in parallel. The parallelization is an important factor to improve
+the feedback loop in merge requests, however, there are some situations that
+you may want to limit the concurrency on deployment
+jobs to run them one by one.
+Resource Group allows you to strategically control
+the concurrency of the jobs for optimizing your continuous deployments workflow with safety.
+
+## Add a resource group
+
+Provided that you have the following pipeline configuration (`.gitlab-ci.yml` file in your repository):
+
+```yaml
+build:
+  stage: build
+  script: echo "Your build script"
+
+deploy:
+  stage: deploy
+  script: echo "Your deployment script"
+  environment: production
+```
+
+Every time you push a new commit to a branch, it runs a new pipeline that has
+two jobs `build` and `deploy`. But if you push multiple commits in a short interval, multiple
+pipelines start running simultaneously, for example:
+
+- The first pipeline runs the jobs `build` -> `deploy`
+- The second pipeline runs the jobs `build` -> `deploy`
+
+In this case, the `deploy` jobs across different pipelines could run concurrently
+to the `production` environment. Running multiple deployment scripts to the same
+infrastructure could harm/confuse the instance and leave it in a corrupted state in the worst case.
+
+In order to ensure that a `deploy` job runs once at a time, you can specify
+[`resource_group` keyword](../yaml/index.md#resource_group) to the concurrency sensitive job:
+
+```yaml
+deploy:
+  ...
+  resource_group: production
+```
+
+With this configuration, the safety on the deployments is assured while you
+can still run `build` jobs concurrently for maximizing the pipeline efficency.
+
+## Requirements
+
+- The basic knowledge of the [GitLab CI/CD pipelines](../pipelines/index.md)
+- The basic knowledge of the [GitLab Environments and Deployments](../environments/index.md)
+- [Developer role](../../user/permissions.md) (or above) in the project to configure CI/CD pipelines.
+
+### Limitations
+
+Only one resource can be attached to a resource group.
+
+## Process modes
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202186) in GitLab 14.3.
+> - [Feature flag `ci_resource_group_process_modes`](https://gitlab.com/gitlab-org/gitlab/-/issues/340380) removed in GitLab 14.4.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/202186) in GitLab 14.4.
+
+You can choose a process mode to strategically control the job concurrency for your deployment preferences.
+The following modes are supported:
+
+- **Unordered:** This is the default process mode that limits the concurrency on running jobs.
+  It's the easiest option to use and useful when you don't care about the execution order
+  of the jobs. It starts processing the jobs whenever a job ready to run.
+- **Oldest first:** This process mode limits the concurrency of the jobs. When a resource is free,
+  it picks the first job from the list of upcoming jobs (`created`, `scheduled`, or `waiting_for_resource` state)
+  that are sorted by pipeline ID in ascending order.
+
+  This mode is useful when you want to ensure that the jobs are executed from the oldest pipeline.
+  This is less efficient compared to the `unordered` mode in terms of the pipeline efficiency,
+  but safer for continuous deployments.
+
+- **Newest first:** This process mode limits the concurrency of the jobs. When a resource is free,
+  it picks the first job from the list of upcoming jobs (`created`, `scheduled` or `waiting_for_resource` state)
+  that are sorted by pipeline ID in descending order.
+
+  This mode is useful when you want to ensure that the jobs are executed from the newest pipeline and
+  cancel all of the old deploy jobs with the [skip outdated deployment jobs](../environments/deployment_safety.md#skip-outdated-deployment-jobs) feature.
+  This is the most efficient option in terms of the pipeline efficiency, but you must ensure that each deployment job is idempotent.
+
+### Change the process mode
+
+To change the process mode of a resource group, you need to use the API and
+send a request to [edit an existing resource group](../../api/resource_groups.md#edit-an-existing-resource-group)
+by specifying the `process_mode`:
+
+- `unordered`
+- `oldest_first`
+- `newest_first`
+
+### An example of difference between the process modes
+
+Consider the following `.gitlab-ci.yml`, where we have two jobs `build` and `deploy`
+each running in their own stage, and the `deploy` job has a resource group set to
+`production`:
+
+```yaml
+build:
+  stage: build
+  script: echo "Your build script"
+
+deploy:
+  stage: deploy
+  script: echo "Your deployment script"
+  environment: production
+  resource_group: production
+```
+
+If three commits are pushed to the project in a short interval, that means that three
+pipelines run almost at the same time:
+
+- The first pipeline runs the jobs `build` -> `deploy`. Let's call this deployment job `deploy-1`.
+- The second pipeline runs the jobs `build` -> `deploy`. Let's call this deployment job `deploy-2`.
+- The third pipeline runs the jobs `build` -> `deploy`. Let's call this deployment job `deploy-3`.
+
+Depending on the process mode of the resource group:
+
+- If the process mode is set to `unordered`:
+  - `deploy-1`, `deploy-2`, and `deploy-3` do not run in parallel.
+  - There is no guarantee on the job execution order, for example, `deploy-1` could run before or after `deploy-3` runs.
+- If the process mode is `oldest_first`:
+  - `deploy-1`, `deploy-2`, and `deploy-3` do not run in parallel.
+  - `deploy-1` runs first, `deploy-2` runs second, and `deploy-3` runs last.
+- If the process mode is `newest_first`:
+  - `deploy-1`, `deploy-2`, and `deploy-3` do not run in parallel.
+  - `deploy-3` runs first, `deploy-2` runs second and `deploy-1` runs last.
+
+## Pipeline-level concurrency control with Cross-Project/Parent-Child pipelines
+
+See the how to [control the pipeline concurrency in cross-project pipelines](../yaml/index.md#pipeline-level-concurrency-control-with-cross-projectparent-child-pipelines).
+
+## API
+
+See the [API documentation](../../api/resource_groups.md).
+
+## Related features
+
+Read more how you can use GitLab for [safe deployments](../environments/deployment_safety.md).
+
+## Troubleshooting
+
+### Avoid dead locks in pipeline configurations
+
+Since [`oldest_first` process mode](#process-modes) enforces the jobs to be executed in a pipeline order,
+there is a case that it doesn't work well with the other CI features.
+
+For example, when you run [a child pipeline](../pipelines/parent_child_pipelines.md)
+that requires the same resource group with the parent pipeline,
+a dead lock could happen. Here is an example of a _bad_ setup:
+
+```yaml
+# BAD
+test:
+  stage: test
+  trigger:
+    include: child-pipeline-requires-production-resource-group.yml
+    strategy: depend
+
+deploy:
+  stage: deploy
+  script: echo
+  resource_group: production
+```
+
+In a parent pipeline, it runs the `test` job that subsequently runs a child pipeline,
+and the [`strategy: depend` option](../yaml/index.md#linking-pipelines-with-triggerstrategy) makes the `test` job wait until the child pipeline has finished.
+The parent pipeline runs the `deploy` job in the next stage, that requires a resource from the `production` resource group.
+If the process mode is `oldest_first`, it executes the jobs from the oldest pipelines, meaning the `deploy` job is going to be executed next.
+
+However, a child pipeline also requires a resource from the `production` resource group.
+Since the child pipeline is newer than the parent pipeline, the child pipeline
+waits until the `deploy` job is finished, something that will never happen.
+
+In this case, you should specify the `resource_group` keyword in the parent pipeline configuration instead:
+
+```yaml
+# GOOD
+test:
+  stage: test
+  trigger:
+    include: child-pipeline.yml
+    strategy: depend
+  resource_group: production # Specify the resource group in the parent pipeline
+
+deploy:
+  stage: deploy
+  script: echo
+  resource_group: production
+```
diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md
deleted file mode 100644
index 0e6c2f63f9e..00000000000
--- a/doc/ci/runners/README.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2021-09-28'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after 2021-09-28. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/runners/build_cloud/linux_build_cloud.md b/doc/ci/runners/build_cloud/linux_build_cloud.md
index 1125d8dbcb4..6cdc93591a7 100644
--- a/doc/ci/runners/build_cloud/linux_build_cloud.md
+++ b/doc/ci/runners/build_cloud/linux_build_cloud.md
@@ -4,7 +4,7 @@ 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
 ---
 
-# Build Cloud runners for Linux
+# Build Cloud runners for Linux **(FREE)**
 
 GitLab Build Cloud runners for Linux run in autoscale mode and are powered by Google Cloud Platform.
 
@@ -15,13 +15,13 @@ GitLab offers Ultimate tier capabilities and included CI/CD minutes per group pe
 All your CI/CD jobs run on [n1-standard-1 instances](https://cloud.google.com/compute/docs/machine-types) with 3.75GB of RAM, CoreOS and the latest Docker Engine
 installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
 region of the VMs is US East1.
-Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
+Each instance is used only for one job. This ensures that any sensitive data left on the system can't be accessed by other people's CI/CD jobs.
 
 The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
 
 Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
 **time out after 3 hours**, regardless of the timeout configured in a
-project. Check the issues [4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
+project. Check the issues [#4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [#4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
 
 Below are the runners' settings.
 
diff --git a/doc/ci/runners/build_cloud/macos/environment.md b/doc/ci/runners/build_cloud/macos/environment.md
index 5336890b931..8a2417186ae 100644
--- a/doc/ci/runners/build_cloud/macos/environment.md
+++ b/doc/ci/runners/build_cloud/macos/environment.md
@@ -4,7 +4,7 @@ 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
 ---
 
-# VM instances and images for Build Cloud for macOS
+# VM instances and images for Build Cloud for macOS **(FREE)**
 
 When you use the Build Cloud for macOS:
 
diff --git a/doc/ci/runners/build_cloud/macos_build_cloud.md b/doc/ci/runners/build_cloud/macos_build_cloud.md
index 794bc2e597d..5d55462fb63 100644
--- a/doc/ci/runners/build_cloud/macos_build_cloud.md
+++ b/doc/ci/runners/build_cloud/macos_build_cloud.md
@@ -4,7 +4,7 @@ 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
 ---
 
-# Build Cloud runners for macOS (Beta)
+# Build Cloud runners for macOS (Beta) **(FREE SAAS)**
 
 The GitLab Build Cloud for macOS Beta provides on-demand runners integrated with GitLab SaaS [CI/CD](../../../ci/index.md).
 Use these runners to build, test, and deploy apps for the Apple ecosystem (macOS, iOS, tvOS). You can take advantage
diff --git a/doc/ci/runners/build_cloud/windows_build_cloud.md b/doc/ci/runners/build_cloud/windows_build_cloud.md
index 0004041a3e8..e01de723055 100644
--- a/doc/ci/runners/build_cloud/windows_build_cloud.md
+++ b/doc/ci/runners/build_cloud/windows_build_cloud.md
@@ -4,7 +4,7 @@ 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
 ---
 
-# Build Cloud runners for Windows (beta)
+# Build Cloud runners for Windows (beta) **(FREE)**
 
 GitLab Build Cloud runners for Windows are in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
 and shouldn't be used for production workloads.
@@ -19,7 +19,7 @@ the Google Cloud Platform. This solution uses an
 developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
 Windows runners execute your CI/CD jobs on `n1-standard-2` instances with
 2 vCPUs and 7.5 GB RAM. You can find a full list of available Windows packages in
-the [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md).
+the [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/main/cookbooks/preinstalled-software/README.md).
 
 We want to keep iterating to get Windows runners in a stable state and
 [generally available](https://about.gitlab.com/handbook/product/gitlab-the-product/#generally-available-ga).
diff --git a/doc/ci/secrets/index.md b/doc/ci/secrets/index.md
index 898d310598f..4d42bc69df8 100644
--- a/doc/ci/secrets/index.md
+++ b/doc/ci/secrets/index.md
@@ -1,6 +1,6 @@
 ---
-stage: Release
-group: Release
+stage: Configure
+group: Configure
 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
 type: concepts, howto
 ---
diff --git a/doc/ci/ssh_keys/index.md b/doc/ci/ssh_keys/index.md
index 1e761643a10..817263374f1 100644
--- a/doc/ci/ssh_keys/index.md
+++ b/doc/ci/ssh_keys/index.md
@@ -10,7 +10,7 @@ type: tutorial
 GitLab currently doesn't have built-in support for managing SSH keys in a build
 environment (where the GitLab Runner runs).
 
-The SSH keys can be useful when:
+Use SSH keys when:
 
 1. You want to checkout internal submodules
 1. You want to download private packages using your package manager (for example, Bundler)
@@ -45,9 +45,9 @@ check the [visibility of your pipelines](../pipelines/settings.md#change-which-u
 
 When your CI/CD jobs run inside Docker containers (meaning the environment is
 contained) and you want to deploy your code in a private server, you need a way
-to access it. This is where an SSH key pair comes in handy.
+to access it. In this case, you can use an SSH key pair.
 
-1. You first need to create an SSH key pair. For more information, follow
+1. You first must create an SSH key pair. For more information, follow
    the instructions to [generate an SSH key](../../ssh/index.md#generate-an-ssh-key-pair).
    **Do not** add a passphrase to the SSH key, or the `before_script` will
    prompt for it.
@@ -101,7 +101,7 @@ to access it. This is where an SSH key pair comes in handy.
 
 1. As a final step, add the _public_ key from the one you created in the first
    step to the services that you want to have an access to from within the build
-   environment. If you are accessing a private GitLab repository you need to add
+   environment. If you are accessing a private GitLab repository you must add
    it as a [deploy key](../../user/project/deploy_keys/index.md).
 
 That's it! You can now have access to private servers or repositories in your
@@ -130,7 +130,7 @@ on, and use that key for all projects that are run on this machine.
 
 1. As a final step, add the _public_ key from the one you created earlier to the
    services that you want to have an access to from within the build environment.
-   If you are accessing a private GitLab repository you need to add it as a
+   If you are accessing a private GitLab repository you must add it as a
    [deploy key](../../user/project/deploy_keys/index.md).
 
 After generating the key, try to sign in to the remote server to accept the
@@ -163,8 +163,8 @@ ssh-keyscan 1.2.3.4
 Create a new [CI/CD variable](../variables/index.md) with
 `SSH_KNOWN_HOSTS` as "Key", and as a "Value" add the output of `ssh-keyscan`.
 
-If you need to connect to multiple servers, all the server host keys
-need to be collected in the **Value** of the variable, one key per line.
+If you must connect to multiple servers, all the server host keys
+must be collected in the **Value** of the variable, one key per line.
 
 NOTE:
 By using a variable instead of `ssh-keyscan` directly inside
@@ -175,7 +175,7 @@ so there's something wrong with the server or the network.
 
 Now that the `SSH_KNOWN_HOSTS` variable is created, in addition to the
 [content of `.gitlab-ci.yml`](#ssh-keys-when-using-the-docker-executor)
-above, here's what more you need to add:
+above, you must add:
 
 ```yaml
 before_script:
@@ -209,5 +209,5 @@ We have set up an [Example SSH Project](https://gitlab.com/gitlab-examples/ssh-p
 that runs on [GitLab.com](https://gitlab.com) using our publicly available
 [shared runners](../runners/index.md).
 
-Want to hack on it? Simply fork it, commit and push your changes. Within a few
+Want to hack on it? Fork it, commit, and push your changes. In a few
 moments the changes is picked by a public runner and the job starts.
diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md
deleted file mode 100644
index 0e6c2f63f9e..00000000000
--- a/doc/ci/triggers/README.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2021-09-28'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after 2021-09-28. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md
index 827a89fa99c..994e9294ff6 100644
--- a/doc/ci/troubleshooting.md
+++ b/doc/ci/troubleshooting.md
@@ -50,7 +50,7 @@ and check if their values are what you expect.
 ## GitLab CI/CD documentation
 
 The [complete `.gitlab-ci.yml` reference](yaml/index.md) contains a full list of
-every keyword you may need to use to configure your pipelines.
+every keyword you can use to configure your pipelines.
 
 You can also look at a large number of pipeline configuration [examples](examples/index.md)
 and [templates](examples/index.md#cicd-templates).
@@ -76,7 +76,7 @@ if you are using that type:
 
 ### Troubleshooting Guides for CI/CD features
 
-There are troubleshooting guides available for some CI/CD features and related topics:
+Troubleshooting guides are available for some CI/CD features and related topics:
 
 - [Container Registry](../user/packages/container_registry/index.md#troubleshooting-the-gitlab-container-registry)
 - [GitLab Runner](https://docs.gitlab.com/runner/faq/)
@@ -118,7 +118,7 @@ Two pipelines can run when pushing a commit to a branch that has an open merge r
 associated with it. Usually one pipeline is a merge request pipeline, and the other
 is a branch pipeline.
 
-This is usually caused by the `rules` configuration, and there are several ways to
+This situation is usually caused by the `rules` configuration, and there are several ways to
 [prevent duplicate pipelines](jobs/job_control.md#avoid-duplicate-pipelines).
 
 #### A job is not in the pipeline
@@ -168,7 +168,7 @@ a branch to its remote repository. To illustrate the problem, suppose you've had
 1. A new pipeline starts running on the `example` branch again, however,
    the previous pipeline (2) fails because of `fatal: reference is not a tree:` error.
 
-This is because the previous pipeline cannot find a checkout-SHA (which is associated with the pipeline record)
+This occurs because the previous pipeline cannot find a checkout-SHA (which is associated with the pipeline record)
 from the `example` branch that the commit history has already been overwritten by the force-push.
 Similarly, [Pipelines for merged results](pipelines/pipelines_for_merged_results.md)
 might have failed intermittently due to [the same reason](pipelines/pipelines_for_merged_results.md#intermittently-pipelines-fail-by-fatal-reference-is-not-a-tree-error).
@@ -199,6 +199,7 @@ latest commit yet. This might be because:
 - You are not using CI/CD pipelines in your project.
 - You are using CI/CD pipelines in your project, but your configuration prevented a pipeline from running on the source branch for your merge request.
 - The latest pipeline was deleted (this is a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214323)).
+- The source branch of the merge request is on a private fork.
 
 After the pipeline is created, the message updates with the pipeline status.
 
@@ -262,7 +263,7 @@ To [prevent duplicate pipelines](jobs/job_control.md#avoid-duplicate-pipelines),
 [`workflow: rules`](yaml/index.md#workflow) or rewrite your rules to control
 which pipelines can run.
 
-### Console workaround if job using resource_group gets stuck
+### Console workaround if job using resource_group gets stuck **(FREE SELF)**
 
 ```ruby
 # find resource group by name
diff --git a/doc/ci/unit_test_reports.md b/doc/ci/unit_test_reports.md
index 7677908e93a..c37d7f27970 100644
--- a/doc/ci/unit_test_reports.md
+++ b/doc/ci/unit_test_reports.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Unit test reports
+# Unit test reports **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45318) in GitLab 11.2. Requires GitLab Runner 11.2 and above.
 > - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39737) from JUnit test reports to Unit test reports in GitLab 13.4.
@@ -67,9 +67,9 @@ execution time and the error output.
 
 ### Number of recent failures
 
-> - [Introduced in Merge Requests](https://gitlab.com/gitlab-org/gitlab/-/issues/241759) in GitLab 13.7.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/241759) in Merge Requests in GitLab 13.7.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/268249) in GitLab 13.8.
-> - [Introduced in Test Reports](https://gitlab.com/gitlab-org/gitlab/-/issues/235525) in GitLab 13.9.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/235525) in Test Reports in GitLab 13.9.
 
 If a test failed in the project's default branch in the last 14 days, a message like
 `Failed {n} time(s) in {default_branch} in the last 14 days` is displayed for that test.
@@ -328,7 +328,7 @@ phpunit:
 ## Viewing Unit test reports on GitLab
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24792) in GitLab 12.5 behind a feature flag (`junit_pipeline_view`), disabled by default.
-> - The feature flag was removed and the feature was [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/216478) in GitLab 13.3.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/216478) in GitLab 13.3.
 
 If JUnit report format XML files are generated and uploaded as part of a pipeline, these reports
 can be viewed inside the pipelines details page. The **Tests** tab on this page
@@ -357,7 +357,7 @@ GitLab does not parse very [large nodes](https://nokogiri.org/tutorials/parsing_
 ## Viewing JUnit screenshots on GitLab
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202114) in GitLab 13.0 behind the `:junit_pipeline_screenshots_view` feature flag, disabled by default.
-> - The feature flag was removed and was [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/216979) in GitLab 13.12.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/216979) in GitLab 13.12.
 
 Upload your screenshots as [artifacts](yaml/index.md#artifactsreportsjunit) to GitLab. If JUnit
 report format XML files contain an `attachment` tag, GitLab parses the attachment. Note that:
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md
deleted file mode 100644
index 0e6c2f63f9e..00000000000
--- a/doc/ci/variables/README.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2021-09-28'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after 2021-09-28. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/variables/index.md b/doc/ci/variables/index.md
index fa4bc6e39fb..8650adf0351 100644
--- a/doc/ci/variables/index.md
+++ b/doc/ci/variables/index.md
@@ -191,7 +191,7 @@ The output is:
 
 ### Add a CI/CD variable to a group
 
-> Support for [environment scopes](https://gitlab.com/gitlab-org/gitlab/-/issues/2874) added to GitLab Premium in 13.11
+> Support for environment scopes [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/2874) in GitLab Premium 13.11
 
 To make a CI/CD variable available to all projects in a group, define a group CI/CD variable.
 
@@ -244,7 +244,7 @@ To add an instance variable:
 1. Select the **Add variable** button, and fill in the details:
 
    - **Key**: Must be one line, with no spaces, using only letters, numbers, or `_`.
-   - **Value**: [In GitLab 13.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/220028),
+   - **Value**: In [GitLab 13.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/220028),
      10,000 characters is allowed. This is also bounded by the limits of the selected
      runner operating system. In GitLab 13.0 to 13.2, 700 characters is allowed.
    - **Type**: [`File` or `Variable`](#cicd-variable-types).
@@ -301,7 +301,7 @@ An alternative to `File` type variables is to:
 
 ```shell
 # Read certificate stored in $KUBE_CA_PEM variable and save it in a new file
-echo "$KUBE_CA_PEM" > "$(pwd)/kube.ca.pem"
+cat "$KUBE_CA_PEM" > "$(pwd)/kube.ca.pem"
 # Pass the newly created file to kubectl
 kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$(pwd)/kube.ca.pem"
 ```
@@ -346,9 +346,9 @@ The value of the variable must:
 - Be a single line.
 - Be 8 characters or longer, consisting only of:
   - Characters from the Base64 alphabet (RFC4648).
-  - The `@` and `:` characters ([In GitLab 12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63043) and later).
-  - The `.` character ([In GitLab 12.10](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29022) and later).
-  - The `~` character ([In GitLab 13.12](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61517) and later).
+  - The `@` and `:` characters (In [GitLab 12.2 and later](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63043)).
+  - The `.` character (In [GitLab 12.10 and later](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29022)).
+  - The `~` character (In [GitLab 13.12 and later](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61517)).
 - Not match the name of an existing predefined or custom CI/CD variable.
 
 NOTE:
diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md
index c8688d2433e..45fa1994342 100644
--- a/doc/ci/variables/predefined_variables.md
+++ b/doc/ci/variables/predefined_variables.md
@@ -20,6 +20,7 @@ There are also [Kubernetes-specific deployment variables](../../user/project/clu
 |------------------------------------------|--------|--------|-------------|
 | `CHAT_CHANNEL`                           | 10.6   | all    | The Source chat channel that triggered the [ChatOps](../chatops/index.md) command. |
 | `CHAT_INPUT`                             | 10.6   | all    | The additional arguments passed with the [ChatOps](../chatops/index.md) command. |
+| `CHAT_USER_ID`                           | 14.4   | all    | The chat service's user ID of the user who triggered the [ChatOps](../chatops/index.md) command. |
 | `CI`                                     | all    | 0.4    | Available for all jobs executed in CI/CD. `true` when available. |
 | `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. |
diff --git a/doc/ci/variables/where_variables_can_be_used.md b/doc/ci/variables/where_variables_can_be_used.md
index 0f9339657fe..9fd1e3eb1a4 100644
--- a/doc/ci/variables/where_variables_can_be_used.md
+++ b/doc/ci/variables/where_variables_can_be_used.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Where variables can be used
+# Where variables can be used **(FREE)**
 
 As it's described in the [CI/CD variables](index.md) docs, you can
 define many different variables. Some of them can be used for all GitLab CI/CD
@@ -65,9 +65,10 @@ because the expansion is done in GitLab before any runner gets the job.
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48627) in GitLab 13.10. [Deployed behind the `variable_inside_variable` feature flag](../../user/feature_flags.md), disabled by default.
 > - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/297382) in GitLab 14.3.
+> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/297382) in GitLab 14.4.
 
 FLAG:
-On self-managed GitLab, by default this feature is disabled. To enable the feature per project or for your entire instance, ask an administrator to [enable the `variable_inside_variable` flag](../../administration/feature_flags.md).
+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 `variable_inside_variable`. On GitLab.com, this feature is available.
 
 GitLab expands job variable values recursively before sending them to the runner. For example:
 
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
deleted file mode 100644
index 0e6c2f63f9e..00000000000
--- a/doc/ci/yaml/README.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: 'index.md'
-remove_date: '2021-09-28'
----
-
-This document was moved to [another location](index.md).
-
-<!-- This redirect file can be deleted after 2021-09-28. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index fb5748788f7..aa44400fffc 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -10,7 +10,7 @@ type: reference
 This document lists the configuration options for your GitLab `.gitlab-ci.yml` file.
 
 - For a quick introduction to GitLab CI/CD, follow the [quick start guide](../quick_start/index.md).
-- For a collection of examples, see [GitLab CI/CD Examples](../examples/README.md).
+- For a collection of examples, see [GitLab CI/CD Examples](../examples/index.md).
 - To view a large `.gitlab-ci.yml` file used in an enterprise, see the [`.gitlab-ci.yml` file for `gitlab`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab-ci.yml).
 
 When you are editing your `.gitlab-ci.yml` file, you can validate it with the
@@ -446,15 +446,15 @@ that proposes expanding this feature to support more variables.
 
 #### `rules` with `include`
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276515) in GitLab 14.2.
-> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/337507) in GitLab 14.3 and is ready for production use.
-> - [Enabled with `ci_include_rules` flag](https://gitlab.com/gitlab-org/gitlab/-/issues/337507) for self-managed GitLab in GitLab 14.3 and is ready for production use.
-
-FLAG:
-On self-managed GitLab, by default this feature is available. To hide the feature per project or for your entire instance, ask an administrator to [disable the `ci_include_rules` flag](../../administration/feature_flags.md). On GitLab.com, this feature is available.
+> - Introduced in GitLab 14.2 [with a flag](../../administration/feature_flags.md) named `ci_include_rules`. Disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/337507) in GitLab 14.3.
+> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/337507) GitLab 14.3.
+> - [Feature flag `ci_include_rules` removed](https://gitlab.com/gitlab-org/gitlab/-/issues/337507) in GitLab 14.4.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/337507) in GitLab 14.4.
 
 You can use [`rules`](#rules) with `include` to conditionally include other configuration files.
-You can only use `rules:if` in `include` with [certain variables](#variables-with-include).
+You can only use [`if` rules](#rulesif) in `include`, and only with [certain variables](#variables-with-include).
+`rules` keywords such as `changes` and `exists` are not supported.
 
 ```yaml
 include:
@@ -746,9 +746,9 @@ Use `before_script` to define an array of commands that should run before each j
 ```yaml
 job:
   before_script:
-    - echo "Execute this command before any `script:` commands."
+    - echo "Execute this command before any 'script:' commands."
   script:
-    - echo "This command executes after the job's `before_script` commands."
+    - echo "This command executes after the job's 'before_script' commands."
 ```
 
 **Additional details**:
@@ -794,7 +794,7 @@ job:
 Scripts you specify in `after_script` execute in a new shell, separate from any
 `before_script` or `script` commands. As a result, they:
 
-- Have a current working directory set back to the default.
+- Have the current working directory set back to the default (according to the [variables which define how the runner processes Git requests](#configure-runner-behavior-with-variables)).
 - Don't have access to changes done by commands defined in the `before_script` or `script`,
   including:
   - Command aliases and variables exported in `script` scripts.
@@ -1178,6 +1178,7 @@ job:
   all rules. You can't mix `when` at the job-level with `when` in rules.
 - Unlike variables in [`script`](../variables/index.md#use-cicd-variables-in-job-scripts)
   sections, variables in rules expressions are always formatted as `$VARIABLE`.
+  - You can use `rules:if` with `include` to [conditionally include other configuration files](#rules-with-include).
 
 **Related topics**:
 
@@ -1701,6 +1702,8 @@ same group or namespace, you can omit them from the `project:` keyword. For exam
 
 The user running the pipeline must have at least `reporter` access to the group or project, or the group/project must have public visibility.
 
+You cannot use cross project artifact downloads in the same job as [`trigger`](#trigger).
+
 ##### Artifact downloads between pipelines in the same project
 
 Use `needs` to download artifacts from different pipelines in the current project.
@@ -2220,7 +2223,7 @@ For more information, see
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) in GitLab 12.6.
 
 Use the `kubernetes` keyword to configure deployments to a
-[Kubernetes cluster](../../user/project/clusters/index.md) that is associated with your project.
+[Kubernetes cluster](../../user/infrastructure/clusters/index.md) that is associated with your project.
 
 For example:
 
@@ -2243,7 +2246,7 @@ For more information, see
 
 NOTE:
 Kubernetes configuration is not supported for Kubernetes clusters
-that are [managed by GitLab](../../user/project/clusters/index.md#gitlab-managed-clusters).
+that are [managed by GitLab](../../user/project/clusters/gitlab_managed_clusters.md).
 To follow progress on support for GitLab-managed clusters, see the
 [relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/38054).
 
@@ -3258,15 +3261,16 @@ job:
 
 ### `coverage`
 
-Use `coverage` to configure how code coverage is extracted from the
-job output.
+Use `coverage` with a custom regular expression to configure how code coverage
+is extracted from the job output. The coverage is shown in the UI if at least one
+line in the job output matches the regular expression.
 
-Regular expressions are the only valid kind of value expected here. So, using
-surrounding `/` is mandatory to consistently and explicitly represent
-a regular expression string. You must escape special characters if you want to
-match them literally.
+To extract the code coverage value in the matching line, GitLab uses this
+regular expression: `\d+(\.\d+)?`.
 
-For example:
+**Possible inputs**: A regular expression. Must start and end with `/`.
+
+**Example of `coverage`**:
 
 ```yaml
 job1:
@@ -3274,14 +3278,20 @@ job1:
   coverage: '/Code coverage: \d+\.\d+/'
 ```
 
-The coverage is shown in the UI if at least one line in the job output matches the regular expression.
-If there is more than one matched line in the job output, the last line is used.
-For the matched line, the first occurrence of `\d+(\.\d+)?` is the code coverage.
-Leading zeros are removed.
+In this example:
+
+1. GitLab checks the job log for a line that matches the regular expression. A line
+   like `Code coverage: 67.89` would match.
+1. GitLab then checks the line to find a match to `\d+(\.\d+)?`. The sample matching
+   line above gives a code coverage of `67.89`.
+
+**Additional details**:
 
-Coverage output from [child pipelines](../pipelines/parent_child_pipelines.md) is not recorded
-or displayed. Check [the related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/280818)
-for more details.
+- If there is more than one matched line in the job output, the last line is used.
+- Leading zeros are removed.
+- Coverage output from [child pipelines](../pipelines/parent_child_pipelines.md)
+  is not recorded or displayed. Check [the related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/280818)
+  for more details.
 
 ### `dast_configuration` **(ULTIMATE)**
 
@@ -3331,56 +3341,38 @@ to select a specific site profile and scanner profile.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3515) in GitLab 11.5, you can control which failures to retry on.
 
-Use `retry` to configure how many times a job is retried in
-case of a failure.
-
-When a job fails, the job is processed again,
-until the limit specified by the `retry` keyword is reached.
+Use `retry` to configure how many times a job is retried if it fails.
+If not defined, defaults to `0` and jobs do not retry.
 
-If `retry` is set to `2`, and a job succeeds in a second run (first retry), it is not retried.
-The `retry` value must be a positive integer, from `0` to `2`
-(two retries maximum, three runs in total).
+When a job fails, the job is processed up to two more times, until it succeeds or
+reaches the maximum number of retries.
 
-The following example retries all failure cases:
-
-```yaml
-test:
-  script: rspec
-  retry: 2
-```
+By default, all failure types cause the job to be retried. Use [`retry:when`](#retrywhen)
+to select which failures to retry on.
 
-By default, a job is retried on all failure cases. To have better control
-over which failures to retry, `retry` can be a hash with the following keys:
+**Keyword type**: Job keyword. You can use it only as part of a job or in the
+[`default:` section](#custom-default-keyword-values).
 
-- `max`: The maximum number of retries.
-- `when`: The failure cases to retry.
+**Possible inputs**: `0` (default), `1`, or `2`.
 
-To retry only runner system failures at maximum two times:
+**Example of `retry`**:
 
 ```yaml
 test:
   script: rspec
-  retry:
-    max: 2
-    when: runner_system_failure
+  retry: 2
 ```
 
-If there is another failure, other than a runner system failure, the job
-is not retried.
+#### `retry:when`
 
-To retry on multiple failure cases, `when` can also be an array of failures:
+Use `retry:when` with `retry:max` to retry jobs for only specific failure cases.
+`retry:max` is the maximum number of retries, like [`retry`](#retry), and can be
+`0`, `1`, or `2`.
 
-```yaml
-test:
-  script: rspec
-  retry:
-    max: 2
-    when:
-      - runner_system_failure
-      - stuck_or_timeout_failure
-```
+**Keyword type**: Job keyword. You can use it only as part of a job or in the
+[`default:` section](#custom-default-keyword-values).
 
-Possible values for `when` are:
+**Possible inputs**: A single failure type, or an array of one or more failure types:
 
 <!--
   If you change any of the values below, make sure to update the `RETRY_WHEN_IN_DOCUMENTATION`
@@ -3396,7 +3388,6 @@ Possible values for `when` are:
 - `api_failure`: Retry on API failure.
 - `stuck_or_timeout_failure`: Retry when the job got stuck or timed out.
 - `runner_system_failure`: Retry if there is a runner system failure (for example, job setup failed).
-- `missing_dependency_failure`: Retry if a dependency is missing.
 - `runner_unsupported`: Retry if the runner is unsupported.
 - `stale_schedule`: Retry if a delayed job could not be executed.
 - `job_execution_timeout`: Retry if the script exceeded the maximum execution time set for the job.
@@ -3405,7 +3396,34 @@ Possible values for `when` are:
 - `scheduler_failure`: Retry if the scheduler failed to assign the job to a runner.
 - `data_integrity_failure`: Retry if there is a structural integrity problem detected.
 
-You can specify the number of [retry attempts for certain stages of job execution](../runners/configure_runners.md#job-stages-attempts) using variables.
+**Example of `retry:when`** (single failure type):
+
+```yaml
+test:
+  script: rspec
+  retry:
+    max: 2
+    when: runner_system_failure
+```
+
+If there is a failure other than a runner system failure, the job is not retried.
+
+**Example of `retry:when`** (array of failure types):
+
+```yaml
+test:
+  script: rspec
+  retry:
+    max: 2
+    when:
+      - runner_system_failure
+      - stuck_or_timeout_failure
+```
+
+**Related topics**:
+
+You can specify the number of [retry attempts for certain stages of job execution](../runners/configure_runners.md#job-stages-attempts)
+using variables.
 
 ### `timeout`
 
@@ -3859,7 +3877,7 @@ can be deployed to, but there can be only one deployment per device at any given
 The `resource_group` value can only contain letters, digits, `-`, `_`, `/`, `$`, `{`, `}`, `.`, and spaces.
 It can't start or end with `/`.
 
-For more information, see [Deployments Safety](../environments/deployment_safety.md).
+For more information, see [Resource Group documentation](../resource_groups/index.md).
 
 #### Pipeline-level concurrency control with Cross-Project/Parent-Child pipelines