Add latest changes from gitlab-org/gitlab@master

32 files changed, 954 insertions, 921 deletions

diff --git a/doc/ci/README.md b/doc/ci/README.md
index c58e02d08d7..c880c1bbefa 100644
--- a/doc/ci/README.md
+++ b/doc/ci/README.md
@@ -73,7 +73,7 @@ GitLab CI/CD supports numerous configuration options:
 | [Custom path for `.gitlab-ci.yml`](pipelines/settings.md#custom-cicd-configuration-file) | Define a custom path for the CI/CD configuration file.                                   |
 | [Git submodules for CI/CD](git_submodules.md)                                           | Configure jobs for using Git submodules.                                                  |
 | [SSH keys for CI/CD](ssh_keys/index.md)                                                | Using SSH keys in your CI pipelines.                                                      |
-| [Pipeline triggers](triggers/README.md)                                                 | Trigger pipelines through the API.                                                        |
+| [Pipeline triggers](triggers/index.md)                                                 | Trigger pipelines through the API.                                                        |
 | [Pipelines for Merge Requests](merge_request_pipelines/index.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. |
 | [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories.                                   |
@@ -123,7 +123,7 @@ Its feature set is listed on the table below according to DevOps stages.
 ## Examples
 
 Find example project code and tutorials for using GitLab CI/CD with a variety of app frameworks, languages, and platforms
-on the [CI Examples](examples/README.md) page.
+on the [CI Examples](examples/index.md) page.
 
 ## Administration **(FREE SELF)**
 
diff --git a/doc/ci/cloud_deployment/ecs/quick_start_guide.md b/doc/ci/cloud_deployment/ecs/quick_start_guide.md
index a801be549df..700a922a74d 100644
--- a/doc/ci/cloud_deployment/ecs/quick_start_guide.md
+++ b/doc/ci/cloud_deployment/ecs/quick_start_guide.md
@@ -14,7 +14,7 @@ In this guide, you begin by creating an ECS cluster manually using the AWS conso
 deploy a simple application that you create from a GitLab template.
 
 These instructions work for both SaaS and self-managed GitLab instances.
-Ensure your own [runners are configured](../../runners/README.md).
+Ensure your own [runners are configured](../../runners/index.md).
 
 ## Prerequisites
 
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index 496ac484a0e..4b7a6b114eb 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -26,7 +26,7 @@ If you don't want to execute a runner in privileged mode,
 but want to use `docker build`, you can also [use kaniko](using_kaniko.md).
 
 If you are using shared runners on GitLab.com, 
-[learn more about how these runners are configured](../runners/README.md).
+[learn more about how these runners are configured](../runners/index.md).
 
 ### Use the shell executor
 
@@ -90,7 +90,7 @@ The Docker image has all of the `docker` tools installed and can run
 the job script in context of the image in privileged mode.
 
 We recommend you use [Docker-in-Docker with TLS enabled](#docker-in-docker-with-tls-enabled),
-which is supported by [GitLab.com shared runners](../runners/README.md).
+which is supported by [GitLab.com shared runners](../runners/index.md).
 
 You should always specify a specific version of the image, like `docker:19.03.12`.
 If you use a tag like `docker:stable`, you have no control over which version is used.
diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md
index 5e294d14f04..2feca97b37b 100644
--- a/doc/ci/docker/using_kaniko.md
+++ b/doc/ci/docker/using_kaniko.md
@@ -133,7 +133,7 @@ The [Least Privilege Container Builds with Kaniko on GitLab](https://www.youtube
 video is a walkthrough of the [Kaniko Docker Build](https://gitlab.com/guided-explorations/containers/kaniko-docker-build)
 Guided Exploration project pipeline. It was tested on:
 
-- [GitLab.com shared runners](../runners/README.md)
+- [GitLab.com shared runners](../runners/index.md)
 - [The Kubernetes runner executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
 
 The example can be copied to your own group or instance for testing. More details
diff --git a/doc/ci/enable_or_disable_ci.md b/doc/ci/enable_or_disable_ci.md
index 268be535591..95f1fa9fb33 100644
--- a/doc/ci/enable_or_disable_ci.md
+++ b/doc/ci/enable_or_disable_ci.md
@@ -11,7 +11,7 @@ To effectively use GitLab CI/CD, you need:
 
 - A valid [`.gitlab-ci.yml`](yaml/README.md) file present at the root directory
   of your project.
-- A [runner](runners/README.md) properly set up.
+- A [runner](runners/index.md) properly set up.
 
 You can read our [quick start guide](quick_start/index.md) to get you started.
 
diff --git a/doc/ci/examples/README.md b/doc/ci/examples/README.md
index 90273190697..5ab8653dc35 100644
--- a/doc/ci/examples/README.md
+++ b/doc/ci/examples/README.md
@@ -1,182 +1,8 @@
 ---
-stage: Verify
-group: Pipeline Execution
-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
-comments: false
-type: index
+redirect_to: 'index.md'
 ---
 
-# GitLab CI/CD Examples
+This document was moved to [another location](index.md).
 
-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.
-
-Examples are available in several forms. As a collection of:
-
-- `.gitlab-ci.yml` [template files](#cicd-templates) maintained in GitLab, for many
-  common frameworks and programming languages.
-- Repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork and adjust them to your own needs. Projects include an example of using [Review Apps with a static site served by NGINX](https://gitlab.com/gitlab-examples/review-apps-nginx/).
-- Examples and [other resources](#other-resources) listed below.
-
-## CI/CD examples
-
-The following table lists examples with step-by-step tutorials that are contained in this section:
-
-| Use case                      | Resource |
-|-------------------------------|----------|
-| Browser performance testing   | [Browser Performance Testing with the Sitespeed.io container](../../user/project/merge_requests/browser_performance_testing.md). |
-| Deployment with Dpl           | [Using `dpl` as deployment tool](deployment/README.md). |
-| GitLab Pages                  | See the [GitLab Pages](../../user/project/pages/index.md) documentation for a complete example of deploying a static site. |
-| End-to-end testing            | [End-to-end testing with GitLab CI/CD and WebdriverIO](end_to_end_testing_webdriverio/index.md). |
-| Load performance testing      | [Load Performance Testing with the k6 container](../../user/project/merge_requests/load_performance_testing.md). |
-| Multi project pipeline        | [Build, test deploy using multi project pipeline](https://gitlab.com/gitlab-examples/upstream-project). |
-| npm with semantic-release     | [Publish npm packages to the GitLab Package Registry using semantic-release](semantic-release.md). |
-| PHP with Laravel, Envoy       | [Test and deploy Laravel applications with GitLab CI/CD and Envoy](laravel_with_gitlab_and_envoy/index.md). |
-| PHP with npm, SCP             | [Running Composer and npm scripts with deployment via SCP in GitLab CI/CD](deployment/composer-npm-deploy.md). |
-| PHP with PHPunit, `atoum`       | [Testing PHP projects](php.md). |
-| Secrets management with Vault | [Authenticating and Reading Secrets With HashiCorp Vault](authenticating-with-hashicorp-vault/index.md). |
-
-### Contributed examples
-
-You can help people that use your favorite programming language by submitting a link
-to a guide for that language. These contributed guides are hosted externally or in
-separate example projects:
-
-| Use case                      | Resource |
-|-------------------------------|----------|
-| Clojure                       | [Test a Clojure application with GitLab CI/CD](https://gitlab.com/gitlab-examples/clojure-web-application). |
-| Game development              | [DevOps and Game Development with GitLab CI/CD](https://gitlab.com/gitlab-examples/gitlab-game-demo/). |
-| Java with Maven               | [How to deploy Maven projects to Artifactory with GitLab CI/CD](https://gitlab.com/gitlab-examples/maven/simple-maven-example). |
-| Java with Spring Boot         | [Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD](https://gitlab.com/gitlab-examples/spring-gitlab-cf-deploy-demo). |
-| Parallel testing Ruby & JS    | [GitLab CI/CD parallel jobs testing for Ruby & JavaScript projects](https://docs.knapsackpro.com/2019/how-to-run-parallel-jobs-for-rspec-tests-on-gitlab-ci-pipeline-and-speed-up-ruby-javascript-testing). |
-| Python on Heroku              | [Test and deploy a Python application with GitLab CI/CD](https://gitlab.com/gitlab-examples/python-getting-started). |
-| Ruby on Heroku                | [Test and deploy a Ruby application with GitLab CI/CD](https://gitlab.com/gitlab-examples/ruby-getting-started). |
-| Scala on Heroku               | [Test and deploy a Scala application to Heroku](https://gitlab.com/gitlab-examples/scala-sbt). |
-
-## CI/CD templates
-
-Get started with GitLab CI/CD and your favorite programming language or framework by using a
-`.gitlab-ci.yml` [template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates).
-
-When you create a `gitlab-ci.yml` file in the UI, you can
-choose one of these templates:
-
-- [Android (`Android.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Android.gitlab-ci.yml)
-- [Android with fastlane (`Android-Fastlane.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Android-Fastlane.gitlab-ci.yml)
-- [Bash (`Bash.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Bash.gitlab-ci.yml)
-- [C++ (`C++.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/C++.gitlab-ci.yml)
-- [Chef (`Chef.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Chef.gitlab-ci.yml)
-- [Clojure (`Clojure.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Clojure.gitlab-ci.yml)
-- [Composer `Composer.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Composer.gitlab-ci.yml)
-- [Crystal (`Crystal.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Crystal.gitlab-ci.yml)
-- [Dart (`Dart.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Dart.gitlab-ci.yml)
-- [Django (`Django.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Django.gitlab-ci.yml)
-- [Docker (`Docker.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Docker.gitlab-ci.yml)
-- [dotNET (`dotNET.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET.gitlab-ci.yml)
-- [dotNET Core (`dotNET-Core.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET-Core.yml)
-- [Elixir (`Elixir.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Elixir.gitlab-ci.yml)
-- [Flutter (`Flutter.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Flutter.gitlab-ci.yml)
-- [goLang (`Go.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Go.gitlab-ci.yml)
-- [Gradle (`Gradle.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Gradle.gitlab-ci.yml)
-- [Grails (`Grails.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Grails.gitlab-ci.yml)
-- [iOS with fastlane (`iOS-Fastlane.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/iOS-Fastlane.gitlab-ci.yml)
-- [Julia (`Julia.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Julia.gitlab-ci.yml)
-- [Laravel (`Laravel.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Laravel.gitlab-ci.yml)
-- [LaTeX (`LaTeX.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/LaTeX.gitlab-ci.yml)
-- [Maven (`Maven.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Maven.gitlab-ci.yml)
-- [Mono (`Mono.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Mono.gitlab-ci.yml)
-- [npm (`npm.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/npm.gitlab-ci.yml)
-- [Node.js (`Nodejs.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Nodejs.gitlab-ci.yml)
-- [OpenShift (`OpenShift.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/OpenShift.gitlab-ci.yml)
-- [Packer (`Packer.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Packer.gitlab-ci.yml)
-- [PHP (`PHP.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/PHP.gitlab-ci.yml)
-- [Python (`Python.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Python.gitlab-ci.yml)
-- [Ruby (`Ruby.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Ruby.gitlab-ci.yml)
-- [Rust (`Rust.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Rust.gitlab-ci.yml)
-- [Scala (`Scala.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Scala.gitlab-ci.yml)
-- [Swift (`Swift.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Swift.gitlab-ci.yml)
-- [Terraform (`Terraform.latest.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.latest.gitlab-ci.yml)
-
-If a programming language or framework template is not in this list, you can contribute
-one. To create a template, submit a merge request
-to [the templates list](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates).
-
-### Adding templates to your GitLab installation **(PREMIUM SELF)**
-
-You can add custom examples and templates to your self-managed GitLab instance.
-Your GitLab administrator can [designate an instance template repository](../../user/admin_area/settings/instance_template_repository.md)
-that contains examples and templates specific to your organization.
-
-## Other resources
-
-This section provides further resources to help you get familiar with various uses of GitLab CI/CD.
-Note that older articles and videos may not reflect the state of the latest GitLab release.
-
-### CI/CD in the cloud
-
-For examples of setting up GitLab CI/CD for cloud-based environments, see:
-
-- [How to set up multi-account AWS SAM deployments with GitLab CI](https://about.gitlab.com/blog/2019/02/04/multi-account-aws-sam-deployments-with-gitlab-ci/)
-- [Automating Kubernetes Deployments with GitLab CI/CD](https://www.youtube.com/watch?v=wEDRfAz6_Uw)
-- [How to autoscale continuous deployment with GitLab Runner on DigitalOcean](https://about.gitlab.com/blog/2018/06/19/autoscale-continuous-deployment-gitlab-runner-digital-ocean/)
-- [How to create a CI/CD pipeline with Auto Deploy to Kubernetes using GitLab and Helm](https://about.gitlab.com/blog/2017/09/21/how-to-create-ci-cd-pipeline-with-autodeploy-to-kubernetes-using-gitlab-and-helm/)
-- [Demo - Deploying from GitLab to OpenShift Container Cluster](https://youtu.be/EwbhA53Jpp4)
-
-See also the following video overviews:
-
-- [Kubernetes, GitLab, and Cloud Native](https://www.youtube.com/watch?v=d-9awBxEbvQ).
-- [Deploying to IBM Cloud with GitLab CI/CD](https://www.youtube.com/watch?v=6ZF4vgKMd-g).
-
-### Customer stories
-
-For some customer experiences with GitLab CI/CD, see:
-
-- [How Verizon Connect reduced data center deploys from 30 days to under 8 hours with GitLab](https://about.gitlab.com/blog/2019/02/14/verizon-customer-story/)
-- [How Wag! cut their release process from 40 minutes to just 6](https://about.gitlab.com/blog/2019/01/16/wag-labs-blog-post/)
-- [How Jaguar Land Rover embraced CI to speed up their software lifecycle](https://about.gitlab.com/blog/2018/07/23/chris-hill-devops-enterprise-summit-talk/)
-
-### Getting started
-
-For some examples to help get you started, see:
-
-- [GitLab CI/CD's 2018 highlights](https://about.gitlab.com/blog/2019/01/21/gitlab-ci-cd-features-improvements/)
-- [A beginner's guide to continuous integration](https://about.gitlab.com/blog/2018/01/22/a-beginners-guide-to-continuous-integration/)
-
-### Implementing GitLab CI/CD
-
-For examples of others who have implemented GitLab CI/CD, see:
-
-- [How to streamline interactions between multiple repositories with multi-project pipelines](https://about.gitlab.com/blog/2018/10/31/use-multiproject-pipelines-with-gitlab-cicd/)
-- [How we used GitLab CI to build GitLab faster](https://about.gitlab.com/blog/2018/05/02/using-gitlab-ci-to-build-gitlab-faster/)
-- [Test all the things in GitLab CI with Docker by example](https://about.gitlab.com/blog/2018/02/05/test-all-the-things-gitlab-ci-docker-examples/)
-- [A Craftsman looks at continuous integration](https://about.gitlab.com/blog/2018/01/17/craftsman-looks-at-continuous-integration/)
-- [Go tools and GitLab: How to do continuous integration like a boss](https://about.gitlab.com/blog/2017/11/27/go-tools-and-gitlab-how-to-do-continuous-integration-like-a-boss/)
-- [GitBot – automating boring Git operations with CI](https://about.gitlab.com/blog/2017/11/02/automating-boring-git-operations-gitlab-ci/)
-- [How to use GitLab CI for Vue.js](https://about.gitlab.com/blog/2017/09/12/vuejs-app-gitlab/)
-- Video: [GitLab CI/CD Deep Dive](https://youtu.be/pBe4t1CD8Fc?t=195)
-- [Dockerizing GitLab Review Apps](https://about.gitlab.com/blog/2017/07/11/dockerizing-review-apps/)
-- [Fast and natural continuous integration with GitLab CI](https://about.gitlab.com/blog/2017/05/22/fast-and-natural-continuous-integration-with-gitlab-ci/)
-- [Demo: CI/CD with GitLab in action](https://about.gitlab.com/blog/2017/03/13/ci-cd-demo/)
-
-### Migrating to GitLab from third-party CI tools
-
-- [Migrating from Jenkins to GitLab](https://youtu.be/RlEVGOpYF5Y)
-
-### Integrating GitLab CI/CD with other systems
-
-To see how you can integrate GitLab CI/CD with third-party systems, see:
-
-- [Streamline and shorten error remediation with Sentry's new GitLab integration](https://about.gitlab.com/blog/2019/01/25/sentry-integration-blog-post/)
-- [How to simplify your smart home configuration with GitLab CI/CD](https://about.gitlab.com/blog/2018/08/02/using-the-gitlab-ci-slash-cd-for-smart-home-configuration-management/)
-- [Demo: GitLab + Jira + Jenkins](https://about.gitlab.com/blog/2018/07/30/gitlab-workflow-with-jira-jenkins/)
-- [Introducing Auto Breakfast from GitLab (sort of)](https://about.gitlab.com/blog/2018/06/29/introducing-auto-breakfast-from-gitlab/)
-
-### Mobile development
-
-For help with using GitLab CI/CD for mobile application development, see:
-
-- [How to publish Android apps to the Google Play Store with GitLab and fastlane](https://about.gitlab.com/blog/2019/01/28/android-publishing-with-gitlab-and-fastlane/)
-- [Setting up GitLab CI for Android projects](https://about.gitlab.com/blog/2018/10/24/setting-up-gitlab-ci-for-android-projects/)
-- [Working with YAML in GitLab CI from the Android perspective](https://about.gitlab.com/blog/2017/11/20/working-with-yaml-gitlab-ci-android/)
-- [How to use GitLab CI and MacStadium to build your macOS or iOS projects](https://about.gitlab.com/blog/2017/05/15/how-to-use-macstadium-and-gitlab-ci-to-build-your-macos-or-ios-projects/)
-- [Setting up GitLab CI for iOS projects](https://about.gitlab.com/blog/2016/03/10/setting-up-gitlab-ci-for-ios-projects/)
+<!-- 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
index 4d2c22a17f0..5ab8653dc35 100644
--- a/doc/ci/examples/deployment/README.md
+++ b/doc/ci/examples/deployment/README.md
@@ -1,131 +1,8 @@
 ---
-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: tutorial
+redirect_to: 'index.md'
 ---
 
-# Using Dpl as deployment tool
+This document was moved to [another location](index.md).
 
-[Dpl](https://github.com/travis-ci/dpl) (pronounced like the letters D-P-L) is a deploy tool made for
-continuous deployment that's developed and used by Travis CI, but can also be
-used with GitLab CI/CD.
-
-Dpl can be used to deploy to any of the [supported providers](https://github.com/travis-ci/dpl#supported-providers).
-
-## Requirements
-
-To use Dpl you need at least Ruby 1.9.3 with ability to install gems.
-
-## Basic usage
-
-Dpl can be installed on any machine with:
-
-```shell
-gem install dpl
-```
-
-This allows you to test all commands from your local terminal, rather than
-having to test it on a CI server.
-
-If you don't have Ruby installed you can do it on Debian-compatible Linux with:
-
-```shell
-apt-get update
-apt-get install ruby-dev
-```
-
-The Dpl provides support for vast number of services, including: Heroku, Cloud Foundry, AWS/S3, and more.
-To use it simply define provider and any additional parameters required by the provider.
-
-For example if you want to use it to deploy your application to Heroku, you need to specify `heroku` as provider, specify `api_key` and `app`.
-All possible parameters can be found in the [Heroku API section](https://github.com/travis-ci/dpl#heroku-api).
-
-```yaml
-staging:
-  stage: deploy
-  script:
-    - gem install dpl
-    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
-```
-
-In the above example we use Dpl to deploy `my-app-staging` to Heroku server with API key stored in `HEROKU_STAGING_API_KEY` secure variable.
-
-To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers).
-
-## 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`).
-It also means that most probably in your Docker container you don't have the Ruby runtime installed.
-You must install it:
-
-```yaml
-staging:
-  stage: deploy
-  script:
-    - apt-get update -yq
-    - apt-get install -y ruby-dev
-    - gem install dpl
-    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
-  only:
-    - master
-```
-
-The first line `apt-get update -yq` updates the list of available packages,
-where second `apt-get install -y ruby-dev` installs the Ruby runtime on system.
-The above example is valid for all Debian-compatible systems.
-
-## Usage in staging and production
-
-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`
-branch to `staging` and all tags to the `production` environment.
-The final `.gitlab-ci.yml` for that setup would look like this:
-
-```yaml
-staging:
-  stage: deploy
-  script:
-    - gem install dpl
-    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
-  only:
-    - master
-
-production:
-  stage: deploy
-  script:
-    - gem install dpl
-    - dpl --provider=heroku --app=my-app-production --api_key=$HEROKU_PRODUCTION_API_KEY
-  only:
-    - tags
-```
-
-We created two deploy jobs that are executed on different events:
-
-1. `staging` is executed for all commits that were pushed to `master` branch,
-1. `production` is executed for all pushed tags.
-
-We also use two secure variables:
-
-1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app,
-1. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
-
-## Storing API keys
-
-To add secure variables, navigate to your project's
-**Settings > CI/CD > Variables**. The variables that are defined
-in the project settings are sent along with the build script to the runner.
-The secure variables are stored out of the repository. Never store secrets in
-your project's `.gitlab-ci.yml`. It is also important that the secret's value
-is hidden in the job log.
-
-You access added variable by prefixing it's name with `$` (on non-Windows runners)
-or `%` (for Windows Batch runners):
-
-1. `$VARIABLE` - use it for non-Windows runners
-1. `%VARIABLE%` - use it for Windows Batch runners
-
-Read more about the [CI/CD variables](../../variables/README.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/index.md b/doc/ci/examples/deployment/index.md
new file mode 100644
index 00000000000..4d2c22a17f0
--- /dev/null
+++ b/doc/ci/examples/deployment/index.md
@@ -0,0 +1,131 @@
+---
+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: tutorial
+---
+
+# Using Dpl as deployment tool
+
+[Dpl](https://github.com/travis-ci/dpl) (pronounced like the letters D-P-L) is a deploy tool made for
+continuous deployment that's developed and used by Travis CI, but can also be
+used with GitLab CI/CD.
+
+Dpl can be used to deploy to any of the [supported providers](https://github.com/travis-ci/dpl#supported-providers).
+
+## Requirements
+
+To use Dpl you need at least Ruby 1.9.3 with ability to install gems.
+
+## Basic usage
+
+Dpl can be installed on any machine with:
+
+```shell
+gem install dpl
+```
+
+This allows you to test all commands from your local terminal, rather than
+having to test it on a CI server.
+
+If you don't have Ruby installed you can do it on Debian-compatible Linux with:
+
+```shell
+apt-get update
+apt-get install ruby-dev
+```
+
+The Dpl provides support for vast number of services, including: Heroku, Cloud Foundry, AWS/S3, and more.
+To use it simply define provider and any additional parameters required by the provider.
+
+For example if you want to use it to deploy your application to Heroku, you need to specify `heroku` as provider, specify `api_key` and `app`.
+All possible parameters can be found in the [Heroku API section](https://github.com/travis-ci/dpl#heroku-api).
+
+```yaml
+staging:
+  stage: deploy
+  script:
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
+```
+
+In the above example we use Dpl to deploy `my-app-staging` to Heroku server with API key stored in `HEROKU_STAGING_API_KEY` secure variable.
+
+To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers).
+
+## 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`).
+It also means that most probably in your Docker container you don't have the Ruby runtime installed.
+You must install it:
+
+```yaml
+staging:
+  stage: deploy
+  script:
+    - apt-get update -yq
+    - apt-get install -y ruby-dev
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
+  only:
+    - master
+```
+
+The first line `apt-get update -yq` updates the list of available packages,
+where second `apt-get install -y ruby-dev` installs the Ruby runtime on system.
+The above example is valid for all Debian-compatible systems.
+
+## Usage in staging and production
+
+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`
+branch to `staging` and all tags to the `production` environment.
+The final `.gitlab-ci.yml` for that setup would look like this:
+
+```yaml
+staging:
+  stage: deploy
+  script:
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
+  only:
+    - master
+
+production:
+  stage: deploy
+  script:
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-production --api_key=$HEROKU_PRODUCTION_API_KEY
+  only:
+    - tags
+```
+
+We created two deploy jobs that are executed on different events:
+
+1. `staging` is executed for all commits that were pushed to `master` branch,
+1. `production` is executed for all pushed tags.
+
+We also use two secure variables:
+
+1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app,
+1. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
+
+## Storing API keys
+
+To add secure variables, navigate to your project's
+**Settings > CI/CD > Variables**. The variables that are defined
+in the project settings are sent along with the build script to the runner.
+The secure variables are stored out of the repository. Never store secrets in
+your project's `.gitlab-ci.yml`. It is also important that the secret's value
+is hidden in the job log.
+
+You access added variable by prefixing it's name with `$` (on non-Windows runners)
+or `%` (for Windows Batch runners):
+
+1. `$VARIABLE` - use it for non-Windows runners
+1. `%VARIABLE%` - use it for Windows Batch runners
+
+Read more about the [CI/CD variables](../../variables/README.md).
diff --git a/doc/ci/examples/index.md b/doc/ci/examples/index.md
new file mode 100644
index 00000000000..9d6a4f53123
--- /dev/null
+++ b/doc/ci/examples/index.md
@@ -0,0 +1,182 @@
+---
+stage: Verify
+group: Pipeline Execution
+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
+comments: false
+type: index
+---
+
+# GitLab CI/CD Examples
+
+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.
+
+Examples are available in several forms. As a collection of:
+
+- `.gitlab-ci.yml` [template files](#cicd-templates) maintained in GitLab, for many
+  common frameworks and programming languages.
+- Repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork and adjust them to your own needs. Projects include an example of using [Review Apps with a static site served by NGINX](https://gitlab.com/gitlab-examples/review-apps-nginx/).
+- Examples and [other resources](#other-resources) listed below.
+
+## CI/CD examples
+
+The following table lists examples with step-by-step tutorials that are contained in this section:
+
+| Use case                      | Resource |
+|-------------------------------|----------|
+| Browser performance testing   | [Browser Performance Testing with the Sitespeed.io container](../../user/project/merge_requests/browser_performance_testing.md). |
+| Deployment with Dpl           | [Using `dpl` as deployment tool](deployment/index.md). |
+| GitLab Pages                  | See the [GitLab Pages](../../user/project/pages/index.md) documentation for a complete example of deploying a static site. |
+| End-to-end testing            | [End-to-end testing with GitLab CI/CD and WebdriverIO](end_to_end_testing_webdriverio/index.md). |
+| Load performance testing      | [Load Performance Testing with the k6 container](../../user/project/merge_requests/load_performance_testing.md). |
+| Multi project pipeline        | [Build, test deploy using multi project pipeline](https://gitlab.com/gitlab-examples/upstream-project). |
+| npm with semantic-release     | [Publish npm packages to the GitLab Package Registry using semantic-release](semantic-release.md). |
+| PHP with Laravel, Envoy       | [Test and deploy Laravel applications with GitLab CI/CD and Envoy](laravel_with_gitlab_and_envoy/index.md). |
+| PHP with npm, SCP             | [Running Composer and npm scripts with deployment via SCP in GitLab CI/CD](deployment/composer-npm-deploy.md). |
+| PHP with PHPunit, `atoum`       | [Testing PHP projects](php.md). |
+| Secrets management with Vault | [Authenticating and Reading Secrets With HashiCorp Vault](authenticating-with-hashicorp-vault/index.md). |
+
+### Contributed examples
+
+You can help people that use your favorite programming language by submitting a link
+to a guide for that language. These contributed guides are hosted externally or in
+separate example projects:
+
+| Use case                      | Resource |
+|-------------------------------|----------|
+| Clojure                       | [Test a Clojure application with GitLab CI/CD](https://gitlab.com/gitlab-examples/clojure-web-application). |
+| Game development              | [DevOps and Game Development with GitLab CI/CD](https://gitlab.com/gitlab-examples/gitlab-game-demo/). |
+| Java with Maven               | [How to deploy Maven projects to Artifactory with GitLab CI/CD](https://gitlab.com/gitlab-examples/maven/simple-maven-example). |
+| Java with Spring Boot         | [Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD](https://gitlab.com/gitlab-examples/spring-gitlab-cf-deploy-demo). |
+| Parallel testing Ruby & JS    | [GitLab CI/CD parallel jobs testing for Ruby & JavaScript projects](https://docs.knapsackpro.com/2019/how-to-run-parallel-jobs-for-rspec-tests-on-gitlab-ci-pipeline-and-speed-up-ruby-javascript-testing). |
+| Python on Heroku              | [Test and deploy a Python application with GitLab CI/CD](https://gitlab.com/gitlab-examples/python-getting-started). |
+| Ruby on Heroku                | [Test and deploy a Ruby application with GitLab CI/CD](https://gitlab.com/gitlab-examples/ruby-getting-started). |
+| Scala on Heroku               | [Test and deploy a Scala application to Heroku](https://gitlab.com/gitlab-examples/scala-sbt). |
+
+## CI/CD templates
+
+Get started with GitLab CI/CD and your favorite programming language or framework by using a
+`.gitlab-ci.yml` [template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates).
+
+When you create a `gitlab-ci.yml` file in the UI, you can
+choose one of these templates:
+
+- [Android (`Android.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Android.gitlab-ci.yml)
+- [Android with fastlane (`Android-Fastlane.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Android-Fastlane.gitlab-ci.yml)
+- [Bash (`Bash.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Bash.gitlab-ci.yml)
+- [C++ (`C++.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/C++.gitlab-ci.yml)
+- [Chef (`Chef.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Chef.gitlab-ci.yml)
+- [Clojure (`Clojure.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Clojure.gitlab-ci.yml)
+- [Composer `Composer.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Composer.gitlab-ci.yml)
+- [Crystal (`Crystal.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Crystal.gitlab-ci.yml)
+- [Dart (`Dart.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Dart.gitlab-ci.yml)
+- [Django (`Django.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Django.gitlab-ci.yml)
+- [Docker (`Docker.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Docker.gitlab-ci.yml)
+- [dotNET (`dotNET.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET.gitlab-ci.yml)
+- [dotNET Core (`dotNET-Core.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET-Core.yml)
+- [Elixir (`Elixir.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Elixir.gitlab-ci.yml)
+- [Flutter (`Flutter.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Flutter.gitlab-ci.yml)
+- [goLang (`Go.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Go.gitlab-ci.yml)
+- [Gradle (`Gradle.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Gradle.gitlab-ci.yml)
+- [Grails (`Grails.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Grails.gitlab-ci.yml)
+- [iOS with fastlane (`iOS-Fastlane.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/iOS-Fastlane.gitlab-ci.yml)
+- [Julia (`Julia.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Julia.gitlab-ci.yml)
+- [Laravel (`Laravel.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Laravel.gitlab-ci.yml)
+- [LaTeX (`LaTeX.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/LaTeX.gitlab-ci.yml)
+- [Maven (`Maven.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Maven.gitlab-ci.yml)
+- [Mono (`Mono.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Mono.gitlab-ci.yml)
+- [npm (`npm.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/npm.gitlab-ci.yml)
+- [Node.js (`Nodejs.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Nodejs.gitlab-ci.yml)
+- [OpenShift (`OpenShift.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/OpenShift.gitlab-ci.yml)
+- [Packer (`Packer.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Packer.gitlab-ci.yml)
+- [PHP (`PHP.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/PHP.gitlab-ci.yml)
+- [Python (`Python.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Python.gitlab-ci.yml)
+- [Ruby (`Ruby.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Ruby.gitlab-ci.yml)
+- [Rust (`Rust.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Rust.gitlab-ci.yml)
+- [Scala (`Scala.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Scala.gitlab-ci.yml)
+- [Swift (`Swift.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Swift.gitlab-ci.yml)
+- [Terraform (`Terraform.latest.gitlab-ci.yml`)](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.latest.gitlab-ci.yml)
+
+If a programming language or framework template is not in this list, you can contribute
+one. To create a template, submit a merge request
+to [the templates list](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates).
+
+### Adding templates to your GitLab installation **(PREMIUM SELF)**
+
+You can add custom examples and templates to your self-managed GitLab instance.
+Your GitLab administrator can [designate an instance template repository](../../user/admin_area/settings/instance_template_repository.md)
+that contains examples and templates specific to your organization.
+
+## Other resources
+
+This section provides further resources to help you get familiar with various uses of GitLab CI/CD.
+Note that older articles and videos may not reflect the state of the latest GitLab release.
+
+### CI/CD in the cloud
+
+For examples of setting up GitLab CI/CD for cloud-based environments, see:
+
+- [How to set up multi-account AWS SAM deployments with GitLab CI](https://about.gitlab.com/blog/2019/02/04/multi-account-aws-sam-deployments-with-gitlab-ci/)
+- [Automating Kubernetes Deployments with GitLab CI/CD](https://www.youtube.com/watch?v=wEDRfAz6_Uw)
+- [How to autoscale continuous deployment with GitLab Runner on DigitalOcean](https://about.gitlab.com/blog/2018/06/19/autoscale-continuous-deployment-gitlab-runner-digital-ocean/)
+- [How to create a CI/CD pipeline with Auto Deploy to Kubernetes using GitLab and Helm](https://about.gitlab.com/blog/2017/09/21/how-to-create-ci-cd-pipeline-with-autodeploy-to-kubernetes-using-gitlab-and-helm/)
+- [Demo - Deploying from GitLab to OpenShift Container Cluster](https://youtu.be/EwbhA53Jpp4)
+
+See also the following video overviews:
+
+- [Kubernetes, GitLab, and Cloud Native](https://www.youtube.com/watch?v=d-9awBxEbvQ).
+- [Deploying to IBM Cloud with GitLab CI/CD](https://www.youtube.com/watch?v=6ZF4vgKMd-g).
+
+### Customer stories
+
+For some customer experiences with GitLab CI/CD, see:
+
+- [How Verizon Connect reduced data center deploys from 30 days to under 8 hours with GitLab](https://about.gitlab.com/blog/2019/02/14/verizon-customer-story/)
+- [How Wag! cut their release process from 40 minutes to just 6](https://about.gitlab.com/blog/2019/01/16/wag-labs-blog-post/)
+- [How Jaguar Land Rover embraced CI to speed up their software lifecycle](https://about.gitlab.com/blog/2018/07/23/chris-hill-devops-enterprise-summit-talk/)
+
+### Getting started
+
+For some examples to help get you started, see:
+
+- [GitLab CI/CD's 2018 highlights](https://about.gitlab.com/blog/2019/01/21/gitlab-ci-cd-features-improvements/)
+- [A beginner's guide to continuous integration](https://about.gitlab.com/blog/2018/01/22/a-beginners-guide-to-continuous-integration/)
+
+### Implementing GitLab CI/CD
+
+For examples of others who have implemented GitLab CI/CD, see:
+
+- [How to streamline interactions between multiple repositories with multi-project pipelines](https://about.gitlab.com/blog/2018/10/31/use-multiproject-pipelines-with-gitlab-cicd/)
+- [How we used GitLab CI to build GitLab faster](https://about.gitlab.com/blog/2018/05/02/using-gitlab-ci-to-build-gitlab-faster/)
+- [Test all the things in GitLab CI with Docker by example](https://about.gitlab.com/blog/2018/02/05/test-all-the-things-gitlab-ci-docker-examples/)
+- [A Craftsman looks at continuous integration](https://about.gitlab.com/blog/2018/01/17/craftsman-looks-at-continuous-integration/)
+- [Go tools and GitLab: How to do continuous integration like a boss](https://about.gitlab.com/blog/2017/11/27/go-tools-and-gitlab-how-to-do-continuous-integration-like-a-boss/)
+- [GitBot – automating boring Git operations with CI](https://about.gitlab.com/blog/2017/11/02/automating-boring-git-operations-gitlab-ci/)
+- [How to use GitLab CI for Vue.js](https://about.gitlab.com/blog/2017/09/12/vuejs-app-gitlab/)
+- Video: [GitLab CI/CD Deep Dive](https://youtu.be/pBe4t1CD8Fc?t=195)
+- [Dockerizing GitLab Review Apps](https://about.gitlab.com/blog/2017/07/11/dockerizing-review-apps/)
+- [Fast and natural continuous integration with GitLab CI](https://about.gitlab.com/blog/2017/05/22/fast-and-natural-continuous-integration-with-gitlab-ci/)
+- [Demo: CI/CD with GitLab in action](https://about.gitlab.com/blog/2017/03/13/ci-cd-demo/)
+
+### Migrating to GitLab from third-party CI tools
+
+- [Migrating from Jenkins to GitLab](https://youtu.be/RlEVGOpYF5Y)
+
+### Integrating GitLab CI/CD with other systems
+
+To see how you can integrate GitLab CI/CD with third-party systems, see:
+
+- [Streamline and shorten error remediation with Sentry's new GitLab integration](https://about.gitlab.com/blog/2019/01/25/sentry-integration-blog-post/)
+- [How to simplify your smart home configuration with GitLab CI/CD](https://about.gitlab.com/blog/2018/08/02/using-the-gitlab-ci-slash-cd-for-smart-home-configuration-management/)
+- [Demo: GitLab + Jira + Jenkins](https://about.gitlab.com/blog/2018/07/30/gitlab-workflow-with-jira-jenkins/)
+- [Introducing Auto Breakfast from GitLab (sort of)](https://about.gitlab.com/blog/2018/06/29/introducing-auto-breakfast-from-gitlab/)
+
+### Mobile development
+
+For help with using GitLab CI/CD for mobile application development, see:
+
+- [How to publish Android apps to the Google Play Store with GitLab and fastlane](https://about.gitlab.com/blog/2019/01/28/android-publishing-with-gitlab-and-fastlane/)
+- [Setting up GitLab CI for Android projects](https://about.gitlab.com/blog/2018/10/24/setting-up-gitlab-ci-for-android-projects/)
+- [Working with YAML in GitLab CI from the Android perspective](https://about.gitlab.com/blog/2017/11/20/working-with-yaml-gitlab-ci-android/)
+- [How to use GitLab CI and MacStadium to build your macOS or iOS projects](https://about.gitlab.com/blog/2017/05/15/how-to-use-macstadium-and-gitlab-ci-to-build-your-macos-or-ios-projects/)
+- [Setting up GitLab CI for iOS projects](https://about.gitlab.com/blog/2016/03/10/setting-up-gitlab-ci-for-ios-projects/)
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 7080ce82b2c..2e019e35f78 100644
--- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
+++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
@@ -106,7 +106,7 @@ sudo apt install acl
 
 ### Add SSH key
 
-Let's suppose we want to deploy our app to the production server from a private repository on GitLab. First, we need to [generate a new SSH key pair **with no passphrase**](../../../ssh/README.md) for the deployer user.
+Let's suppose we want to deploy our app to the production server from a private repository on GitLab. First, we need to [generate a new SSH key pair **with no passphrase**](../../../ssh/index.md) for the deployer user.
 
 After that, we need to copy the private key, which will be used to connect to our server as the deployer user with SSH, to be able to automate our deployment process:
 
@@ -530,7 +530,7 @@ That's a lot to take in, isn't it? Let's run through it step by step.
 
 #### Image and Services
 
-[Runners](../../runners/README.md) run the script defined by `.gitlab-ci.yml`.
+[Runners](../../runners/index.md) run the script defined by `.gitlab-ci.yml`.
 The `image` keyword tells the runners which image to use.
 The `services` keyword defines additional images [that are linked to the main image](../../services/index.md).
 Here we use the container image we created before as our main image and also use MySQL 5.7 as a service.
diff --git a/doc/ci/examples/php.md b/doc/ci/examples/php.md
index 9e0ff992d40..8184879a738 100644
--- a/doc/ci/examples/php.md
+++ b/doc/ci/examples/php.md
@@ -270,7 +270,7 @@ gitlab-runner exec shell test:app
 
 We have set up an [Example PHP Project](https://gitlab.com/gitlab-examples/php) for your convenience
 that runs on [GitLab.com](https://gitlab.com) using our publicly available
-[shared runners](../runners/README.md).
+[shared runners](../runners/index.md).
 
 Want to hack on it? Simply fork it, commit, and push your changes. Within a few
 moments the changes are picked by a public runner and the job begins.
diff --git a/doc/ci/interactive_web_terminal/index.md b/doc/ci/interactive_web_terminal/index.md
index cbf92438488..46abcf4a21d 100644
--- a/doc/ci/interactive_web_terminal/index.md
+++ b/doc/ci/interactive_web_terminal/index.md
@@ -16,7 +16,7 @@ is deployed, some [security precautions](../../administration/integration/termin
 taken to protect the users.
 
 NOTE:
-[Shared runners on GitLab.com](../runners/README.md) do not
+[Shared runners on GitLab.com](../runners/index.md) do not
 provide an interactive web terminal. Follow [this
 issue](https://gitlab.com/gitlab-org/gitlab/-/issues/24674) for progress on
 adding support. For groups and projects hosted on GitLab.com, interactive web
diff --git a/doc/ci/jobs/index.md b/doc/ci/jobs/index.md
index f359eecf01b..09c5463d165 100644
--- a/doc/ci/jobs/index.md
+++ b/doc/ci/jobs/index.md
@@ -29,7 +29,7 @@ jobs, where each of the jobs executes a different command.
 Of course a command can execute code directly (`./configure;make;make install`)
 or run a script (`test.sh`) in the repository.
 
-Jobs are picked up by [runners](../runners/README.md) and executed in the
+Jobs are picked up by [runners](../runners/index.md) and executed in the
 environment of the runner. What is important is that each job is run
 independently from each other.
 
diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md
index 27eda577b46..1ca1bce979d 100644
--- a/doc/ci/jobs/job_control.md
+++ b/doc/ci/jobs/job_control.md
@@ -225,7 +225,7 @@ check the value of the `$CI_PIPELINE_SOURCE` variable:
 | `pipeline`                    | For [multi-project pipelines](../multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](../yaml/README.md#trigger) keyword. |
 | `push`                        | For pipelines triggered by a `git push` event, including for branches and tags.                                                                                                                                                  |
 | `schedule`                    | For [scheduled pipelines](../pipelines/schedules.md).                                                                                                                                                                            |
-| `trigger`                     | For pipelines created by using a [trigger token](../triggers/README.md#trigger-token).                                                                                                                                           |
+| `trigger`                     | For pipelines created by using a [trigger token](../triggers/index.md#trigger-token).                                                                                                                                           |
 | `web`                         | For pipelines created by using **Run pipeline** button in the GitLab UI, from the project's **CI/CD > Pipelines** section.                                                                                                       |
 | `webide`                      | For pipelines created by using the [WebIDE](../../user/project/web_ide/index.md).                                                                                                                                                |
 
@@ -306,7 +306,7 @@ to control when to add jobs to pipelines.
 In the following example, `job` runs only for:
 
 - Git tags
-- [Triggers](../triggers/README.md#trigger-token)
+- [Triggers](../triggers/index.md#trigger-token)
 - [Scheduled pipelines](../pipelines/schedules.md)
 
 ```yaml
diff --git a/doc/ci/migration/jenkins.md b/doc/ci/migration/jenkins.md
index 812f1caa5d1..328f4b38aad 100644
--- a/doc/ci/migration/jenkins.md
+++ b/doc/ci/migration/jenkins.md
@@ -17,7 +17,7 @@ that were able to quickly complete this migration:
 
 1. Start by reading the GitLab CI/CD [Quick Start Guide](../quick_start/index.md) and [important product differences](#important-product-differences).
 1. Learn the importance of [managing the organizational transition](#managing-the-organizational-transition).
-1. [Add runners](../runners/README.md) to your GitLab instance.
+1. [Add runners](../runners/index.md) to your GitLab instance.
 1. Educate and enable your developers to independently perform the following steps in their projects:
    1. Review the [Quick Start Guide](../quick_start/index.md) and [Pipeline Configuration Reference](../yaml/README.md).
    1. Use the [Jenkins Wrapper](#jenkinsfile-wrapper) to temporarily maintain fragile Jenkins jobs.
@@ -77,8 +77,8 @@ There are some high level differences between the products worth mentioning:
   - on push
   - on [schedule](../pipelines/schedules.md)
   - from the [GitLab UI](../pipelines/index.md#run-a-pipeline-manually)
-  - by [API call](../triggers/README.md)
-  - by [webhook](../triggers/README.md#triggering-a-pipeline-from-a-webhook)
+  - by [API call](../triggers/index.md)
+  - by [webhook](../triggers/index.md#triggering-a-pipeline-from-a-webhook)
   - by [ChatOps](../chatops/index.md)
 
 - You can control which jobs run in which cases, depending on how they are triggered,
@@ -122,7 +122,7 @@ There are some high level differences between the products worth mentioning:
 ## Agents vs. runners
 
 Both Jenkins agents and GitLab runners are the hosts that run jobs. To convert the
-Jenkins agent, simply uninstall it and then [install and register the runner](../runners/README.md).
+Jenkins agent, simply uninstall it and then [install and register the runner](../runners/index.md).
 Runners do not require much overhead, so you can size them similarly to the Jenkins
 agents you were using.
 
@@ -137,7 +137,7 @@ There are some important differences in the way runners work in comparison to ag
   Use autoscaling to provision runners only when needed, and scale down when not needed.
   This is similar to ephemeral agents in Jenkins.
 
-If you are using `gitlab.com`, you can take advantage of our [shared runner fleet](../runners/README.md)
+If you are using `gitlab.com`, you can take advantage of our [shared runner fleet](../runners/index.md)
 to run jobs without provisioning your own runners. We are investigating making them
 [available for self-managed instances](https://gitlab.com/groups/gitlab-org/-/epics/835)
 as well.
@@ -227,7 +227,7 @@ and is meant to be a mapping of concepts there to concepts in GitLab.
 
 #### `agent`
 
-The agent section is used to define how a pipeline executes. For GitLab, we use [runners](../runners/README.md)
+The agent section is used to define how a pipeline executes. For GitLab, we use [runners](../runners/index.md)
 to provide this capability. You can configure your own runners in Kubernetes or on any host, or take advantage
 of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users).
 We also support using [tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) to direct different jobs
diff --git a/doc/ci/multi_project_pipelines.md b/doc/ci/multi_project_pipelines.md
index abdf01521db..ac800e1baee 100644
--- a/doc/ci/multi_project_pipelines.md
+++ b/doc/ci/multi_project_pipelines.md
@@ -258,7 +258,7 @@ upstream_bridge:
 
 > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) to GitLab Free in 12.4.
 
-When you use the [`CI_JOB_TOKEN` to trigger pipelines](triggers/README.md#ci-job-token),
+When you use the [`CI_JOB_TOKEN` to trigger pipelines](triggers/index.md#ci-job-token),
 GitLab recognizes the source of the job token. The pipelines become related,
 so you can visualize their relationships on pipeline graphs.
 
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index f499e4077f4..f9a58c04fa2 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -20,7 +20,7 @@ Pipelines comprise:
 - Jobs, which define *what* to do. For example, jobs that compile or test code.
 - Stages, which define *when* to run the jobs. For example, stages that run tests after stages that compile the code.
 
-Jobs are executed by [runners](../runners/README.md). Multiple jobs in the same stage are executed in parallel,
+Jobs are executed by [runners](../runners/index.md). Multiple jobs in the same stage are executed in parallel,
 if there are enough concurrent runners.
 
 If *all* jobs in a stage succeed, the pipeline moves on to the next stage.
@@ -441,5 +441,5 @@ GitLab provides API endpoints to:
 - Perform basic functions. For more information, see [Pipelines API](../../api/pipelines.md).
 - Maintain pipeline schedules. For more information, see [Pipeline schedules API](../../api/pipeline_schedules.md).
 - Trigger pipeline runs. For more information, see:
-  - [Triggering pipelines through the API](../triggers/README.md).
+  - [Triggering pipelines through the API](../triggers/index.md).
   - [Pipeline triggers API](../../api/pipeline_triggers.md).
diff --git a/doc/ci/pipelines/pipeline_efficiency.md b/doc/ci/pipelines/pipeline_efficiency.md
index 5bb435dddf6..f0b0b8cf3d5 100644
--- a/doc/ci/pipelines/pipeline_efficiency.md
+++ b/doc/ci/pipelines/pipeline_efficiency.md
@@ -33,7 +33,7 @@ heavily influenced by the:
 - The ["critical path"](#directed-acyclic-graphs-dag-visualization), which represents
   the minimum and maximum pipeline duration.
 
-Additional points to pay attention relate to [GitLab Runners](../runners/README.md):
+Additional points to pay attention relate to [GitLab Runners](../runners/index.md):
 
 - Availability of the runners and the resources they are provisioned with.
 - Build dependencies and their installation time.
@@ -62,7 +62,7 @@ It's important to understand and document the pipeline workflows, and discuss po
 actions and changes. Refactoring pipelines may need careful interaction between teams
 in the DevSecOps lifecycle.
 
-Pipeline analysis can help identify issues with cost efficiency. For example, [runners](../runners/README.md)
+Pipeline analysis can help identify issues with cost efficiency. For example, [runners](../runners/index.md)
 hosted with a paid cloud service may be provisioned with:
 
 - More resources than needed for CI/CD pipelines, wasting money.
diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index a64efd50f6f..d23118f7c38 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -22,7 +22,7 @@ Review Apps:
 
 - Provide an automatic live preview of changes made in a feature branch by spinning up a dynamic environment for your merge requests.
 - Allow designers and product managers to see your changes without needing to check out your branch and run your changes in a sandbox environment.
-- Are fully integrated with the [GitLab DevOps LifeCycle](../../README.md#the-entire-devops-lifecycle).
+- Are fully integrated with the [GitLab DevOps LifeCycle](../../index.md#the-entire-devops-lifecycle).
 - Allow you to deploy your changes wherever you want.
 
 ![Review Apps Workflow](img/continuous-delivery-review-apps.svg)
diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md
index 45113c480c7..5ab8653dc35 100644
--- a/doc/ci/runners/README.md
+++ b/doc/ci/runners/README.md
@@ -1,289 +1,8 @@
 ---
-stage: Verify
-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
-type: reference
+redirect_to: 'index.md'
 ---
 
-# GitLab SaaS runners
+This document was moved to [another location](index.md).
 
-If you are using self-managed GitLab or you want to use your own runners on GitLab.com, you can
-[install and configure your own runners](https://docs.gitlab.com/runner/install/).
-
-If you are using GitLab SaaS (GitLab.com), your CI jobs automatically run on shared runners. No configuration is required.
-Your jobs can run on [Linux](#linux-shared-runners) or [Windows](#windows-shared-runners-beta).
-
-The number of minutes you can use on these shared runners depends on your
-[quota](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota),
-which depends on your [subscription plan](../../subscriptions/gitlab_com/index.md#ci-pipeline-minutes).
-
-## Linux shared runners
-
-Linux shared runners on GitLab.com run in autoscale mode and are powered by Google Cloud Platform.
-
-Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each job, thus maximizing security. These shared runners are available for users and customers on GitLab.com.
-
-GitLab offers Ultimate tier capabilities and included CI/CD minutes per group per month for our [Open Source](https://about.gitlab.com/solutions/open-source/join/), [Education](https://about.gitlab.com/solutions/education/), and [Startups](https://about.gitlab.com/solutions/startups/) programs. For private projects, GitLab offers various [plans](https://about.gitlab.com/pricing/), starting with a Free tier.
-
-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.
-
-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.
-
-Below are the shared runners settings.
-
-| Setting                               | GitLab.com                                        | Default    |
-| -----------                           | -----------------                                 | ---------- |
-| [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) | [Runner versions dashboard](https://dashboards.gitlab.com/d/000000159/ci?from=now-1h&to=now&refresh=5m&orgId=1&panelId=12&fullscreen&theme=light) | - |
-| Executor                              | `docker+machine`                                  | -          |
-| Default Docker image                  | `ruby:2.5`                                        | -          |
-| `privileged` (run [Docker in Docker](https://hub.docker.com/_/docker/)) | `true`          | `false`    |
-
-### Pre-clone script
-
-Linux shared runners on GitLab.com provide a way to run commands in a CI
-job before the runner attempts to run `git init` and `git fetch` to
-download a GitLab repository. The
-[`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
-can be used for:
-
-- Seeding the build directory with repository data
-- Sending a request to a server
-- Downloading assets from a CDN
-- Any other commands that must run before the `git init`
-
-To use this feature, define a [CI/CD variable](../../ci/variables/README.md#custom-cicd-variables) called
-`CI_PRE_CLONE_SCRIPT` that contains a bash script.
-
-[This example](../../development/pipelines.md#pre-clone-step)
-demonstrates how you might use a pre-clone step to seed the build
-directory.
-
-### `config.toml`
-
-The full contents of our `config.toml` are:
-
-NOTE:
-Settings that are not public are shown as `X`.
-
-**Google Cloud Platform**
-
-```toml
-concurrent = X
-check_interval = 1
-metrics_server = "X"
-sentry_dsn = "X"
-
-[[runners]]
-  name = "docker-auto-scale"
-  request_concurrency = X
-  url = "https://gitlab.com/"
-  token = "SHARED_RUNNER_TOKEN"
-  pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
-  executor = "docker+machine"
-  environment = [
-    "DOCKER_DRIVER=overlay2",
-    "DOCKER_TLS_CERTDIR="
-  ]
-  limit = X
-  [runners.docker]
-    image = "ruby:2.5"
-    privileged = true
-    volumes = [
-      "/certs/client",
-      "/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro" # Make kaniko builds work on GCP.
-    ]
-  [runners.machine]
-    IdleCount = 50
-    IdleTime = 3600
-    MaxBuilds = 1 # For security reasons we delete the VM after job has finished so it's not reused.
-    MachineName = "srm-%s"
-    MachineDriver = "google"
-    MachineOptions = [
-      "google-project=PROJECT",
-      "google-disk-size=25",
-      "google-machine-type=n1-standard-1",
-      "google-username=core",
-      "google-tags=gitlab-com,srm",
-      "google-use-internal-ip",
-      "google-zone=us-east1-d",
-      "engine-opt=mtu=1460", # Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
-      "google-machine-image=PROJECT/global/images/IMAGE",
-      "engine-opt=ipv6", # This will create IPv6 interfaces in the containers.
-      "engine-opt=fixed-cidr-v6=fc00::/7",
-      "google-operation-backoff-initial-interval=2" # Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
-    ]
-    [[runners.machine.autoscaling]]
-      Periods = ["* * * * * sat,sun *"]
-      Timezone = "UTC"
-      IdleCount = 70
-      IdleTime = 3600
-    [[runners.machine.autoscaling]]
-      Periods = ["* 30-59 3 * * * *", "* 0-30 4 * * * *"]
-      Timezone = "UTC"
-      IdleCount = 700
-      IdleTime = 3600
-  [runners.cache]
-    Type = "gcs"
-    Shared = true
-    [runners.cache.gcs]
-      CredentialsFile = "/path/to/file"
-      BucketName = "bucket-name"
-```
-
-## Windows shared runners (beta)
-
-The Windows shared runners are in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
-and shouldn't be used for production workloads.
-
-During this beta period, the [shared runner pipeline quota](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
-applies for groups and projects in the same manner as Linux runners. This may
-change when the beta period ends, as discussed in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
-
-Windows shared runners on GitLab.com autoscale by launching virtual machines on
-the Google Cloud Platform. This solution uses an
-[autoscaling driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/tree/master/docs/readme.md)
-developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
-Windows shared 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).
-
-We want to keep iterating to get Windows shared runners in a stable state and
-[generally available](https://about.gitlab.com/handbook/product/gitlab-the-product/#generally-available-ga).
-You can follow our work towards this goal in the
-[related epic](https://gitlab.com/groups/gitlab-org/-/epics/2162).
-
-### Configuration
-
-The full contents of our `config.toml` are:
-
-NOTE:
-Settings that aren't public are shown as `X`.
-
-```toml
-concurrent = X
-check_interval = 3
-
-[[runners]]
-  name = "windows-runner"
-  url = "https://gitlab.com/"
-  token = "TOKEN"
-  executor = "custom"
-  builds_dir = "C:\\GitLab-Runner\\builds"
-  cache_dir = "C:\\GitLab-Runner\\cache"
-  shell  = "powershell"
-  [runners.custom]
-    config_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    config_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "config"]
-    prepare_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    prepare_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "prepare"]
-    run_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    run_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "run"]
-    cleanup_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    cleanup_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "cleanup"]
-```
-
-The full contents of our `autoscaler/config.toml` are:
-
-```toml
-Provider = "gcp"
-Executor = "winrm"
-OS = "windows"
-LogLevel = "info"
-LogFormat = "text"
-LogFile = "C:\\GitLab-Runner\\autoscaler\\autoscaler.log"
-VMTag = "windows"
-
-[GCP]
-  ServiceAccountFile = "PATH"
-  Project = "some-project-df9323"
-  Zone = "us-east1-c"
-  MachineType = "n1-standard-2"
-  Image = "IMAGE"
-  DiskSize = 50
-  DiskType = "pd-standard"
-  Subnetwork = "default"
-  Network = "default"
-  Tags = ["TAGS"]
-  Username = "gitlab_runner"
-
-[WinRM]
-  MaximumTimeout = 3600
-  ExecutionMaxRetries = 0
-
-[ProviderCache]
-  Enabled = true
-  Directory = "C:\\GitLab-Runner\\autoscaler\\machines"
-```
-
-### Example
-
-Below is a simple `.gitlab-ci.yml` file to show how to start using the
-Windows shared runners:
-
-```yaml
-.shared_windows_runners:
-  tags:
-    - shared-windows
-    - windows
-    - windows-1809
-
-stages:
-  - build
-  - test
-
-before_script:
- - Set-Variable -Name "time" -Value (date -Format "%H:%m")
- - echo ${time}
- - echo "started by ${GITLAB_USER_NAME}"
-
-build:
-  extends:
-    - .shared_windows_runners
-  stage: build
-  script:
-    - echo "running scripts in the build job"
-
-test:
-  extends:
-    - .shared_windows_runners
-  stage: test
-  script:
-    - echo "running scripts in the test job"
-```
-
-### Limitations and known issues
-
-- All the limitations mentioned in our [beta
-  definition](https://about.gitlab.com/handbook/product/#beta).
-- The average provisioning time for a new Windows VM is 5 minutes.
-  This means that you may notice slower build start times
-  on the Windows shared runner fleet during the beta. In a future
-  release we intend to update the autoscaler to enable
-  the pre-provisioning of virtual machines. This is intended to significantly reduce
-  the time it takes to provision a VM on the Windows fleet. You can
-  follow along in the [related issue](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/issues/32).
-- The Windows shared runner fleet may be unavailable occasionally
-  for maintenance or updates.
-- The Windows shared runner virtual machine instances do not use the
-  GitLab Docker executor. This means that you can't specify
-  [`image`](../../ci/yaml/README.md#image) or [`services`](../../ci/yaml/README.md#services) in
-  your pipeline configuration.
-- For the beta release, we have included a set of software packages in
-  the base VM image. If your CI job requires additional software that's
-  not included in this list, then you must add installation
-  commands to [`before_script`](../../ci/yaml/README.md#before_script) or [`script`](../../ci/yaml/README.md#script) to install the required
-  software. Note that each job runs on a new VM instance, so the
-  installation of additional software packages needs to be repeated for
-  each job in your pipeline.
-- The job may stay in a pending state for longer than the
-  Linux shared runners.
-- There is the possibility that we introduce breaking changes which will
-  require updates to pipelines that are using the Windows shared runner
-  fleet.
+<!-- 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/index.md b/doc/ci/runners/index.md
new file mode 100644
index 00000000000..45113c480c7
--- /dev/null
+++ b/doc/ci/runners/index.md
@@ -0,0 +1,289 @@
+---
+stage: Verify
+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
+type: reference
+---
+
+# GitLab SaaS runners
+
+If you are using self-managed GitLab or you want to use your own runners on GitLab.com, you can
+[install and configure your own runners](https://docs.gitlab.com/runner/install/).
+
+If you are using GitLab SaaS (GitLab.com), your CI jobs automatically run on shared runners. No configuration is required.
+Your jobs can run on [Linux](#linux-shared-runners) or [Windows](#windows-shared-runners-beta).
+
+The number of minutes you can use on these shared runners depends on your
+[quota](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota),
+which depends on your [subscription plan](../../subscriptions/gitlab_com/index.md#ci-pipeline-minutes).
+
+## Linux shared runners
+
+Linux shared runners on GitLab.com run in autoscale mode and are powered by Google Cloud Platform.
+
+Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each job, thus maximizing security. These shared runners are available for users and customers on GitLab.com.
+
+GitLab offers Ultimate tier capabilities and included CI/CD minutes per group per month for our [Open Source](https://about.gitlab.com/solutions/open-source/join/), [Education](https://about.gitlab.com/solutions/education/), and [Startups](https://about.gitlab.com/solutions/startups/) programs. For private projects, GitLab offers various [plans](https://about.gitlab.com/pricing/), starting with a Free tier.
+
+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.
+
+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.
+
+Below are the shared runners settings.
+
+| Setting                               | GitLab.com                                        | Default    |
+| -----------                           | -----------------                                 | ---------- |
+| [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) | [Runner versions dashboard](https://dashboards.gitlab.com/d/000000159/ci?from=now-1h&to=now&refresh=5m&orgId=1&panelId=12&fullscreen&theme=light) | - |
+| Executor                              | `docker+machine`                                  | -          |
+| Default Docker image                  | `ruby:2.5`                                        | -          |
+| `privileged` (run [Docker in Docker](https://hub.docker.com/_/docker/)) | `true`          | `false`    |
+
+### Pre-clone script
+
+Linux shared runners on GitLab.com provide a way to run commands in a CI
+job before the runner attempts to run `git init` and `git fetch` to
+download a GitLab repository. The
+[`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
+can be used for:
+
+- Seeding the build directory with repository data
+- Sending a request to a server
+- Downloading assets from a CDN
+- Any other commands that must run before the `git init`
+
+To use this feature, define a [CI/CD variable](../../ci/variables/README.md#custom-cicd-variables) called
+`CI_PRE_CLONE_SCRIPT` that contains a bash script.
+
+[This example](../../development/pipelines.md#pre-clone-step)
+demonstrates how you might use a pre-clone step to seed the build
+directory.
+
+### `config.toml`
+
+The full contents of our `config.toml` are:
+
+NOTE:
+Settings that are not public are shown as `X`.
+
+**Google Cloud Platform**
+
+```toml
+concurrent = X
+check_interval = 1
+metrics_server = "X"
+sentry_dsn = "X"
+
+[[runners]]
+  name = "docker-auto-scale"
+  request_concurrency = X
+  url = "https://gitlab.com/"
+  token = "SHARED_RUNNER_TOKEN"
+  pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
+  executor = "docker+machine"
+  environment = [
+    "DOCKER_DRIVER=overlay2",
+    "DOCKER_TLS_CERTDIR="
+  ]
+  limit = X
+  [runners.docker]
+    image = "ruby:2.5"
+    privileged = true
+    volumes = [
+      "/certs/client",
+      "/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro" # Make kaniko builds work on GCP.
+    ]
+  [runners.machine]
+    IdleCount = 50
+    IdleTime = 3600
+    MaxBuilds = 1 # For security reasons we delete the VM after job has finished so it's not reused.
+    MachineName = "srm-%s"
+    MachineDriver = "google"
+    MachineOptions = [
+      "google-project=PROJECT",
+      "google-disk-size=25",
+      "google-machine-type=n1-standard-1",
+      "google-username=core",
+      "google-tags=gitlab-com,srm",
+      "google-use-internal-ip",
+      "google-zone=us-east1-d",
+      "engine-opt=mtu=1460", # Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
+      "google-machine-image=PROJECT/global/images/IMAGE",
+      "engine-opt=ipv6", # This will create IPv6 interfaces in the containers.
+      "engine-opt=fixed-cidr-v6=fc00::/7",
+      "google-operation-backoff-initial-interval=2" # Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
+    ]
+    [[runners.machine.autoscaling]]
+      Periods = ["* * * * * sat,sun *"]
+      Timezone = "UTC"
+      IdleCount = 70
+      IdleTime = 3600
+    [[runners.machine.autoscaling]]
+      Periods = ["* 30-59 3 * * * *", "* 0-30 4 * * * *"]
+      Timezone = "UTC"
+      IdleCount = 700
+      IdleTime = 3600
+  [runners.cache]
+    Type = "gcs"
+    Shared = true
+    [runners.cache.gcs]
+      CredentialsFile = "/path/to/file"
+      BucketName = "bucket-name"
+```
+
+## Windows shared runners (beta)
+
+The Windows shared runners are in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
+and shouldn't be used for production workloads.
+
+During this beta period, the [shared runner pipeline quota](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
+applies for groups and projects in the same manner as Linux runners. This may
+change when the beta period ends, as discussed in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
+
+Windows shared runners on GitLab.com autoscale by launching virtual machines on
+the Google Cloud Platform. This solution uses an
+[autoscaling driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/tree/master/docs/readme.md)
+developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
+Windows shared 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).
+
+We want to keep iterating to get Windows shared runners in a stable state and
+[generally available](https://about.gitlab.com/handbook/product/gitlab-the-product/#generally-available-ga).
+You can follow our work towards this goal in the
+[related epic](https://gitlab.com/groups/gitlab-org/-/epics/2162).
+
+### Configuration
+
+The full contents of our `config.toml` are:
+
+NOTE:
+Settings that aren't public are shown as `X`.
+
+```toml
+concurrent = X
+check_interval = 3
+
+[[runners]]
+  name = "windows-runner"
+  url = "https://gitlab.com/"
+  token = "TOKEN"
+  executor = "custom"
+  builds_dir = "C:\\GitLab-Runner\\builds"
+  cache_dir = "C:\\GitLab-Runner\\cache"
+  shell  = "powershell"
+  [runners.custom]
+    config_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
+    config_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "config"]
+    prepare_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
+    prepare_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "prepare"]
+    run_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
+    run_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "run"]
+    cleanup_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
+    cleanup_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "cleanup"]
+```
+
+The full contents of our `autoscaler/config.toml` are:
+
+```toml
+Provider = "gcp"
+Executor = "winrm"
+OS = "windows"
+LogLevel = "info"
+LogFormat = "text"
+LogFile = "C:\\GitLab-Runner\\autoscaler\\autoscaler.log"
+VMTag = "windows"
+
+[GCP]
+  ServiceAccountFile = "PATH"
+  Project = "some-project-df9323"
+  Zone = "us-east1-c"
+  MachineType = "n1-standard-2"
+  Image = "IMAGE"
+  DiskSize = 50
+  DiskType = "pd-standard"
+  Subnetwork = "default"
+  Network = "default"
+  Tags = ["TAGS"]
+  Username = "gitlab_runner"
+
+[WinRM]
+  MaximumTimeout = 3600
+  ExecutionMaxRetries = 0
+
+[ProviderCache]
+  Enabled = true
+  Directory = "C:\\GitLab-Runner\\autoscaler\\machines"
+```
+
+### Example
+
+Below is a simple `.gitlab-ci.yml` file to show how to start using the
+Windows shared runners:
+
+```yaml
+.shared_windows_runners:
+  tags:
+    - shared-windows
+    - windows
+    - windows-1809
+
+stages:
+  - build
+  - test
+
+before_script:
+ - Set-Variable -Name "time" -Value (date -Format "%H:%m")
+ - echo ${time}
+ - echo "started by ${GITLAB_USER_NAME}"
+
+build:
+  extends:
+    - .shared_windows_runners
+  stage: build
+  script:
+    - echo "running scripts in the build job"
+
+test:
+  extends:
+    - .shared_windows_runners
+  stage: test
+  script:
+    - echo "running scripts in the test job"
+```
+
+### Limitations and known issues
+
+- All the limitations mentioned in our [beta
+  definition](https://about.gitlab.com/handbook/product/#beta).
+- The average provisioning time for a new Windows VM is 5 minutes.
+  This means that you may notice slower build start times
+  on the Windows shared runner fleet during the beta. In a future
+  release we intend to update the autoscaler to enable
+  the pre-provisioning of virtual machines. This is intended to significantly reduce
+  the time it takes to provision a VM on the Windows fleet. You can
+  follow along in the [related issue](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/issues/32).
+- The Windows shared runner fleet may be unavailable occasionally
+  for maintenance or updates.
+- The Windows shared runner virtual machine instances do not use the
+  GitLab Docker executor. This means that you can't specify
+  [`image`](../../ci/yaml/README.md#image) or [`services`](../../ci/yaml/README.md#services) in
+  your pipeline configuration.
+- For the beta release, we have included a set of software packages in
+  the base VM image. If your CI job requires additional software that's
+  not included in this list, then you must add installation
+  commands to [`before_script`](../../ci/yaml/README.md#before_script) or [`script`](../../ci/yaml/README.md#script) to install the required
+  software. Note that each job runs on a new VM instance, so the
+  installation of additional software packages needs to be repeated for
+  each job in your pipeline.
+- The job may stay in a pending state for longer than the
+  Linux shared runners.
+- There is the possibility that we introduce breaking changes which will
+  require updates to pipelines that are using the Windows shared runner
+  fleet.
diff --git a/doc/ci/services/gitlab.md b/doc/ci/services/gitlab.md
index 81a17300e55..1f6ea828b9c 100644
--- a/doc/ci/services/gitlab.md
+++ b/doc/ci/services/gitlab.md
@@ -11,7 +11,7 @@ Many applications need to access JSON APIs, so application tests might need acce
 to APIs too. The following example shows how to use GitLab as a microservice to give
 tests access to the GitLab API.
 
-1. Configure a [runner](../runners/README.md) with the Docker or Kubernetes executor.
+1. Configure a [runner](../runners/index.md) with the Docker or Kubernetes executor.
 1. In your `.gitlab-ci.yml` add:
 
    ```yaml
diff --git a/doc/ci/services/mysql.md b/doc/ci/services/mysql.md
index 1e0762ca010..f1dc3cb43b8 100644
--- a/doc/ci/services/mysql.md
+++ b/doc/ci/services/mysql.md
@@ -12,7 +12,7 @@ need it for your tests to run.
 
 ## Use MySQL with the Docker executor
 
-If you want to use a MySQL container, you can use [GitLab Runner](../runners/README.md) with the Docker executor.
+If you want to use a MySQL container, you can use [GitLab Runner](../runners/index.md) with the Docker executor.
 
 This example shows you how to set a username and password that GitLab uses to access the MySQL container. If you do not set a username and password, you must use `root`.
 
@@ -130,5 +130,5 @@ GitLab Runner with the Shell executor.
 ## Example project
 
 To view a MySQL example, create a fork of this [sample project](https://gitlab.com/gitlab-examples/mysql).
-This project uses publicly-available [shared runners](../runners/README.md) on [GitLab.com](https://gitlab.com).
+This project uses publicly-available [shared runners](../runners/index.md) on [GitLab.com](https://gitlab.com).
 Update the README.md file, commit your changes, and view the CI/CD pipeline to see it in action.
diff --git a/doc/ci/services/postgres.md b/doc/ci/services/postgres.md
index 8451d56a71c..c5513934bc9 100644
--- a/doc/ci/services/postgres.md
+++ b/doc/ci/services/postgres.md
@@ -13,7 +13,7 @@ do this with the Docker and Shell executors of GitLab Runner.
 
 ## Use PostgreSQL with the Docker executor
 
-If you're using [GitLab Runner](../runners/README.md) with the Docker executor,
+If you're using [GitLab Runner](../runners/index.md) with the Docker executor,
 you basically have everything set up already.
 
 First, in your `.gitlab-ci.yml` add:
@@ -121,7 +121,7 @@ Database: nice_marmot
 
 We have set up an [Example PostgreSQL Project](https://gitlab.com/gitlab-examples/postgres) for your
 convenience that runs on [GitLab.com](https://gitlab.com) using our publicly
-available [shared runners](../runners/README.md).
+available [shared runners](../runners/index.md).
 
 Want to hack on it? Fork it, commit, and push your changes. Within a few
 moments the changes are picked by a public runner and the job begins.
diff --git a/doc/ci/services/redis.md b/doc/ci/services/redis.md
index 71d3ffb1c60..d8c7b805864 100644
--- a/doc/ci/services/redis.md
+++ b/doc/ci/services/redis.md
@@ -13,7 +13,7 @@ do this with the Docker and Shell executors of GitLab Runner.
 
 ## Use Redis with the Docker executor
 
-If you are using [GitLab Runner](../runners/README.md) with the Docker executor
+If you are using [GitLab Runner](../runners/index.md) with the Docker executor
 you basically have everything set up already.
 
 First, in your `.gitlab-ci.yml` add:
@@ -67,7 +67,7 @@ Host: localhost
 
 We have set up an [Example Redis Project](https://gitlab.com/gitlab-examples/redis) for your convenience
 that runs on [GitLab.com](https://gitlab.com) using our publicly available
-[shared runners](../runners/README.md).
+[shared runners](../runners/index.md).
 
 Want to hack on it? Simply fork it, commit and push your changes. Within a few
 moments the changes are picked by a public runner and the job begins.
diff --git a/doc/ci/ssh_keys/index.md b/doc/ci/ssh_keys/index.md
index 85755f9a179..c80389adb82 100644
--- a/doc/ci/ssh_keys/index.md
+++ b/doc/ci/ssh_keys/index.md
@@ -48,7 +48,7 @@ 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.
 
 1. You first need to create an SSH key pair. For more information, follow
-   the instructions to [generate an SSH key](../../ssh/README.md#generate-an-ssh-key-pair).
+   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.
 
@@ -124,7 +124,7 @@ on, and use that key for all projects that are run on this machine.
    ```
 
 1. Generate the SSH key pair as described in the instructions to
-   [generate an SSH key](../../ssh/README.md#generate-an-ssh-key-pair).
+   [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.
 
@@ -207,7 +207,7 @@ before_script:
 
 We have set up an [Example SSH Project](https://gitlab.com/gitlab-examples/ssh-private-key/) for your convenience
 that runs on [GitLab.com](https://gitlab.com) using our publicly available
-[shared runners](../runners/README.md).
+[shared runners](../runners/index.md).
 
 Want to hack on it? Simply fork it, commit and push your changes. Within 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
index b8d0df44598..5ab8653dc35 100644
--- a/doc/ci/triggers/README.md
+++ b/doc/ci/triggers/README.md
@@ -1,288 +1,8 @@
 ---
-stage: Verify
-group: Pipeline Execution
-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: tutorial
+redirect_to: 'index.md'
 ---
 
-# Triggering pipelines through the API **(FREE)**
+This document was moved to [another location](index.md).
 
-Triggers can be used to force a pipeline rerun of a specific `ref` (branch or
-tag) with an API call.
-
-## Authentication tokens
-
-The following methods of authentication are supported:
-
-- [Trigger token](#trigger-token)
-- [CI job token](#ci-job-token)
-
-If using the `$CI_PIPELINE_SOURCE` [predefined CI/CD variable](../variables/predefined_variables.md)
-to limit which jobs run in a pipeline, the value could be either `pipeline` or `trigger`,
-depending on which trigger method is used.
-
-| `$CI_PIPELINE_SOURCE` value | Trigger method |
-|-----------------------------|----------------|
-| `pipeline`                  | Using the `trigger:` keyword in the CI/CD configuration file, or using the trigger API with `$CI_JOB_TOKEN`. |
-| `trigger`                   | Using the trigger API using a generated trigger token |
-
-This also applies when using the `pipelines` or `triggers` keywords with the legacy [`only/except` basic syntax](../yaml/README.md#only--except).
-
-### Trigger token
-
-A unique trigger token can be obtained when [adding a new trigger](#adding-a-new-trigger).
-
-WARNING:
-Passing plain text tokens in public projects is a security issue. Potential
-attackers can impersonate the user that exposed their trigger token publicly in
-their `.gitlab-ci.yml` file. Use [CI/CD variables](../variables/README.md)
-to protect trigger tokens.
-
-### CI job token
-
-You can use the `CI_JOB_TOKEN` [CI/CD variable](../variables/README.md#predefined-cicd-variables) (used to authenticate
-with the [GitLab Container Registry](../../user/packages/container_registry/index.md)) in the following cases.
-
-#### When used with multi-project pipelines
-
-> - Use of `CI_JOB_TOKEN` for multi-project pipelines was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2017) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.3.
-> - Use of `CI_JOB_TOKEN` for multi-project pipelines was [made available](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) in all tiers in GitLab 12.4.
-
-This way of triggering can only be used when invoked inside `.gitlab-ci.yml`,
-and it creates a dependent pipeline relation visible on the
-[pipeline graph](../multi_project_pipelines.md). For example:
-
-```yaml
-trigger_pipeline:
-  stage: deploy
-  script:
-    - curl --request POST --form "token=$CI_JOB_TOKEN" --form ref=main "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
-  rules:
-    - if: $CI_COMMIT_TAG
-```
-
-Pipelines triggered that way also expose a special variable:
-`CI_PIPELINE_SOURCE=pipeline`.
-
-Read more about the [pipelines trigger API](../../api/pipeline_triggers.md).
-
-#### When a pipeline depends on the artifacts of another pipeline **(PREMIUM)**
-
-> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2346) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.5.
-
-With the introduction of dependencies between different projects, one of
-them may need to access artifacts created by a previous one. This process
-must be granted for authorized accesses, and it can be done using the
-`CI_JOB_TOKEN` variable that identifies a specific job. For example:
-
-```yaml
-build_submodule:
-  image: debian
-  stage: test
-  script:
-    - apt update && apt install -y unzip
-    - curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/download?job=test&job_token=$CI_JOB_TOKEN"
-    - unzip artifacts.zip
-  rules:
-    - if: $CI_COMMIT_TAG
-```
-
-This allows you to use that for multi-project pipelines and download artifacts
-from any project to which you have access as this follows the same principles
-with the [permission model](../../user/permissions.md#job-permissions).
-
-Read more about the [jobs API](../../api/job_artifacts.md#download-the-artifacts-archive).
-
-## Adding a new trigger
-
-Go to your
-**Settings > CI/CD** under **Triggers** to add a new trigger. The **Add trigger** button creates
-a new token which you can then use to trigger a rerun of this
-particular project's pipeline.
-
-Every new trigger you create, gets assigned a different token which you can
-then use inside your scripts or `.gitlab-ci.yml`. You also have a nice
-overview of the time the triggers were last used.
-
-![Triggers page overview](img/triggers_page.png)
-
-## Revoking a trigger
-
-You can revoke a trigger any time by going at your project's
-**Settings > CI/CD** under **Triggers** and hitting the **Revoke** button.
-The action is irreversible.
-
-## Triggering a pipeline
-
-To trigger a job you need to send a `POST` request to the GitLab API endpoint:
-
-```plaintext
-POST /projects/:id/trigger/pipeline
-```
-
-The required parameters are the [trigger's `token`](#authentication-tokens)
-and the Git `ref` on which the trigger is performed. Valid refs are
-branches or tags. The `:id` of a project can be found by
-[querying the API](../../api/projects.md) or by visiting the **CI/CD**
-settings page which provides self-explanatory examples.
-
-When a rerun of a pipeline is triggered, jobs are marked as triggered `by API` in
-**CI/CD > Jobs**.
-
-You can see which trigger caused a job to run by visiting the single job page.
-A part of the trigger's token is exposed in the UI as you can see from the image
-below.
-
-![Marked as triggered on a single job page](img/trigger_single_job.png)
-
-By using cURL you can trigger a pipeline rerun with minimal effort, for example:
-
-```shell
-curl --request POST \
-     --form token=TOKEN \
-     --form ref=main \
-     "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
-```
-
-In this case, the pipeline for the project with ID `9` runs on the `main` branch.
-
-Alternatively, you can pass the `token` and `ref` arguments in the query string:
-
-```shell
-curl --request POST \
-    "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline?token=TOKEN&ref=main"
-```
-
-You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that
-you have two projects, A and B, and you want to trigger a pipeline on the `main`
-branch of project B whenever a tag on project A is created. This is the job you
-need to add in project A's `.gitlab-ci.yml`:
-
-```yaml
-trigger_pipeline:
-  stage: deploy
-  script:
-    - 'curl --request POST --form token=TOKEN --form ref=main "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"'
-  rules:
-    - if: $CI_COMMIT_TAG
-```
-
-This means that whenever a new tag is pushed on project A, the job runs and the
-`trigger_pipeline` job is executed, triggering the pipeline for project B. The
-`stage: deploy` ensures that this job runs only after all jobs with
-`stage: test` complete successfully.
-
-## Triggering a pipeline from a webhook
-
-To trigger a job from a webhook of another project you need to add the following
-webhook URL for Push and Tag events (change the project ID, ref and token):
-
-```plaintext
-https://gitlab.example.com/api/v4/projects/9/ref/main/trigger/pipeline?token=TOKEN
-```
-
-You should pass `ref` as part of the URL, to take precedence over `ref` from
-the webhook body that designates the branch ref that fired the trigger in the
-source repository. Be sure to URL-encode `ref` if it contains slashes.
-
-### Using webhook payload in the triggered pipeline
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31197) in GitLab 13.9.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/321027) in GitLab 13.11.
-
-If you trigger a pipeline by using a webhook, you can access the webhook payload with
-the `TRIGGER_PAYLOAD` [predefined CI/CD variable](../variables/predefined_variables.md).
-The payload is exposed as a [file-type variable](../variables/README.md#cicd-variable-types),
-so you can access the data with `cat $TRIGGER_PAYLOAD` or a similar command.
-
-## Making use of trigger variables
-
-You can pass any number of arbitrary variables in the trigger API call and they
-are available in GitLab CI/CD so that they can be used in your `.gitlab-ci.yml`
-file. The parameter is of the form:
-
-```plaintext
-variables[key]=value
-```
-
-This information is also exposed in the UI. Please note that _values_ are only viewable by Owners and Maintainers.
-
-![Job variables in UI](img/trigger_variables.png)
-
-Using trigger variables can be proven useful for a variety of reasons:
-
-- Identifiable jobs. Since the variable is exposed in the UI you can know
-  why the pipeline was triggered if you pass a variable that explains the
-  purpose.
-- Conditional job processing. You can have conditional jobs that run whenever
-  a certain variable is present.
-
-Consider the following `.gitlab-ci.yml` where we set three
-[stages](../yaml/README.md#stages) and the `upload_package` job is run only
-when all jobs from the test and build stages pass. When the `UPLOAD_TO_S3`
-variable is non-zero, `make upload` is run.
-
-```yaml
-stages:
-  - test
-  - build
-  - package
-
-run_tests:
-  stage: test
-  script:
-    - make test
-
-build_package:
-  stage: build
-  script:
-    - make build
-
-upload_package:
-  stage: package
-  script:
-    - if [ -n "${UPLOAD_TO_S3}" ]; then make upload; fi
-```
-
-You can then trigger a pipeline while you pass the `UPLOAD_TO_S3` variable
-and the script of the `upload_package` job is run:
-
-```shell
-curl --request POST \
-  --form token=TOKEN \
-  --form ref=main \
-  --form "variables[UPLOAD_TO_S3]=true" \
-  "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
-```
-
-Trigger variables have the [highest priority](../variables/README.md#cicd-variable-precedence)
-of all types of variables.
-
-## Using cron to trigger nightly pipelines
-
-Whether you craft a script or just run cURL directly, you can trigger jobs
-in conjunction with cron. The example below triggers a job on the `main` branch
-of project with ID `9` every night at `00:30`:
-
-```shell
-30 0 * * * curl --request POST --form token=TOKEN --form ref=main "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
-```
-
-This behavior can also be achieved through the GitLab UI with
-[pipeline schedules](../pipelines/schedules.md).
-
-## Legacy triggers
-
-Old triggers, created before GitLab 9.0 are marked as legacy.
-
-Triggers with the legacy label do not have an associated user and only have
-access to the current project. They are considered deprecated and might be
-removed with one of the future versions of GitLab.
-
-## Troubleshooting
-
-### '404 not found' when triggering a pipeline
-
-A response of `{"message":"404 Not Found"}` when triggering a pipeline might be caused
-by using a Personal Access Token instead of a trigger token. [Add a new trigger](#adding-a-new-trigger)
-and use that token to authenticate when triggering a pipeline.
+<!-- 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/triggers/index.md b/doc/ci/triggers/index.md
new file mode 100644
index 00000000000..b8d0df44598
--- /dev/null
+++ b/doc/ci/triggers/index.md
@@ -0,0 +1,288 @@
+---
+stage: Verify
+group: Pipeline Execution
+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: tutorial
+---
+
+# Triggering pipelines through the API **(FREE)**
+
+Triggers can be used to force a pipeline rerun of a specific `ref` (branch or
+tag) with an API call.
+
+## Authentication tokens
+
+The following methods of authentication are supported:
+
+- [Trigger token](#trigger-token)
+- [CI job token](#ci-job-token)
+
+If using the `$CI_PIPELINE_SOURCE` [predefined CI/CD variable](../variables/predefined_variables.md)
+to limit which jobs run in a pipeline, the value could be either `pipeline` or `trigger`,
+depending on which trigger method is used.
+
+| `$CI_PIPELINE_SOURCE` value | Trigger method |
+|-----------------------------|----------------|
+| `pipeline`                  | Using the `trigger:` keyword in the CI/CD configuration file, or using the trigger API with `$CI_JOB_TOKEN`. |
+| `trigger`                   | Using the trigger API using a generated trigger token |
+
+This also applies when using the `pipelines` or `triggers` keywords with the legacy [`only/except` basic syntax](../yaml/README.md#only--except).
+
+### Trigger token
+
+A unique trigger token can be obtained when [adding a new trigger](#adding-a-new-trigger).
+
+WARNING:
+Passing plain text tokens in public projects is a security issue. Potential
+attackers can impersonate the user that exposed their trigger token publicly in
+their `.gitlab-ci.yml` file. Use [CI/CD variables](../variables/README.md)
+to protect trigger tokens.
+
+### CI job token
+
+You can use the `CI_JOB_TOKEN` [CI/CD variable](../variables/README.md#predefined-cicd-variables) (used to authenticate
+with the [GitLab Container Registry](../../user/packages/container_registry/index.md)) in the following cases.
+
+#### When used with multi-project pipelines
+
+> - Use of `CI_JOB_TOKEN` for multi-project pipelines was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2017) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.3.
+> - Use of `CI_JOB_TOKEN` for multi-project pipelines was [made available](https://gitlab.com/gitlab-org/gitlab/-/issues/31573) in all tiers in GitLab 12.4.
+
+This way of triggering can only be used when invoked inside `.gitlab-ci.yml`,
+and it creates a dependent pipeline relation visible on the
+[pipeline graph](../multi_project_pipelines.md). For example:
+
+```yaml
+trigger_pipeline:
+  stage: deploy
+  script:
+    - curl --request POST --form "token=$CI_JOB_TOKEN" --form ref=main "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
+  rules:
+    - if: $CI_COMMIT_TAG
+```
+
+Pipelines triggered that way also expose a special variable:
+`CI_PIPELINE_SOURCE=pipeline`.
+
+Read more about the [pipelines trigger API](../../api/pipeline_triggers.md).
+
+#### When a pipeline depends on the artifacts of another pipeline **(PREMIUM)**
+
+> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2346) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.5.
+
+With the introduction of dependencies between different projects, one of
+them may need to access artifacts created by a previous one. This process
+must be granted for authorized accesses, and it can be done using the
+`CI_JOB_TOKEN` variable that identifies a specific job. For example:
+
+```yaml
+build_submodule:
+  image: debian
+  stage: test
+  script:
+    - apt update && apt install -y unzip
+    - curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/download?job=test&job_token=$CI_JOB_TOKEN"
+    - unzip artifacts.zip
+  rules:
+    - if: $CI_COMMIT_TAG
+```
+
+This allows you to use that for multi-project pipelines and download artifacts
+from any project to which you have access as this follows the same principles
+with the [permission model](../../user/permissions.md#job-permissions).
+
+Read more about the [jobs API](../../api/job_artifacts.md#download-the-artifacts-archive).
+
+## Adding a new trigger
+
+Go to your
+**Settings > CI/CD** under **Triggers** to add a new trigger. The **Add trigger** button creates
+a new token which you can then use to trigger a rerun of this
+particular project's pipeline.
+
+Every new trigger you create, gets assigned a different token which you can
+then use inside your scripts or `.gitlab-ci.yml`. You also have a nice
+overview of the time the triggers were last used.
+
+![Triggers page overview](img/triggers_page.png)
+
+## Revoking a trigger
+
+You can revoke a trigger any time by going at your project's
+**Settings > CI/CD** under **Triggers** and hitting the **Revoke** button.
+The action is irreversible.
+
+## Triggering a pipeline
+
+To trigger a job you need to send a `POST` request to the GitLab API endpoint:
+
+```plaintext
+POST /projects/:id/trigger/pipeline
+```
+
+The required parameters are the [trigger's `token`](#authentication-tokens)
+and the Git `ref` on which the trigger is performed. Valid refs are
+branches or tags. The `:id` of a project can be found by
+[querying the API](../../api/projects.md) or by visiting the **CI/CD**
+settings page which provides self-explanatory examples.
+
+When a rerun of a pipeline is triggered, jobs are marked as triggered `by API` in
+**CI/CD > Jobs**.
+
+You can see which trigger caused a job to run by visiting the single job page.
+A part of the trigger's token is exposed in the UI as you can see from the image
+below.
+
+![Marked as triggered on a single job page](img/trigger_single_job.png)
+
+By using cURL you can trigger a pipeline rerun with minimal effort, for example:
+
+```shell
+curl --request POST \
+     --form token=TOKEN \
+     --form ref=main \
+     "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
+```
+
+In this case, the pipeline for the project with ID `9` runs on the `main` branch.
+
+Alternatively, you can pass the `token` and `ref` arguments in the query string:
+
+```shell
+curl --request POST \
+    "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline?token=TOKEN&ref=main"
+```
+
+You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that
+you have two projects, A and B, and you want to trigger a pipeline on the `main`
+branch of project B whenever a tag on project A is created. This is the job you
+need to add in project A's `.gitlab-ci.yml`:
+
+```yaml
+trigger_pipeline:
+  stage: deploy
+  script:
+    - 'curl --request POST --form token=TOKEN --form ref=main "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"'
+  rules:
+    - if: $CI_COMMIT_TAG
+```
+
+This means that whenever a new tag is pushed on project A, the job runs and the
+`trigger_pipeline` job is executed, triggering the pipeline for project B. The
+`stage: deploy` ensures that this job runs only after all jobs with
+`stage: test` complete successfully.
+
+## Triggering a pipeline from a webhook
+
+To trigger a job from a webhook of another project you need to add the following
+webhook URL for Push and Tag events (change the project ID, ref and token):
+
+```plaintext
+https://gitlab.example.com/api/v4/projects/9/ref/main/trigger/pipeline?token=TOKEN
+```
+
+You should pass `ref` as part of the URL, to take precedence over `ref` from
+the webhook body that designates the branch ref that fired the trigger in the
+source repository. Be sure to URL-encode `ref` if it contains slashes.
+
+### Using webhook payload in the triggered pipeline
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31197) in GitLab 13.9.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/321027) in GitLab 13.11.
+
+If you trigger a pipeline by using a webhook, you can access the webhook payload with
+the `TRIGGER_PAYLOAD` [predefined CI/CD variable](../variables/predefined_variables.md).
+The payload is exposed as a [file-type variable](../variables/README.md#cicd-variable-types),
+so you can access the data with `cat $TRIGGER_PAYLOAD` or a similar command.
+
+## Making use of trigger variables
+
+You can pass any number of arbitrary variables in the trigger API call and they
+are available in GitLab CI/CD so that they can be used in your `.gitlab-ci.yml`
+file. The parameter is of the form:
+
+```plaintext
+variables[key]=value
+```
+
+This information is also exposed in the UI. Please note that _values_ are only viewable by Owners and Maintainers.
+
+![Job variables in UI](img/trigger_variables.png)
+
+Using trigger variables can be proven useful for a variety of reasons:
+
+- Identifiable jobs. Since the variable is exposed in the UI you can know
+  why the pipeline was triggered if you pass a variable that explains the
+  purpose.
+- Conditional job processing. You can have conditional jobs that run whenever
+  a certain variable is present.
+
+Consider the following `.gitlab-ci.yml` where we set three
+[stages](../yaml/README.md#stages) and the `upload_package` job is run only
+when all jobs from the test and build stages pass. When the `UPLOAD_TO_S3`
+variable is non-zero, `make upload` is run.
+
+```yaml
+stages:
+  - test
+  - build
+  - package
+
+run_tests:
+  stage: test
+  script:
+    - make test
+
+build_package:
+  stage: build
+  script:
+    - make build
+
+upload_package:
+  stage: package
+  script:
+    - if [ -n "${UPLOAD_TO_S3}" ]; then make upload; fi
+```
+
+You can then trigger a pipeline while you pass the `UPLOAD_TO_S3` variable
+and the script of the `upload_package` job is run:
+
+```shell
+curl --request POST \
+  --form token=TOKEN \
+  --form ref=main \
+  --form "variables[UPLOAD_TO_S3]=true" \
+  "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
+```
+
+Trigger variables have the [highest priority](../variables/README.md#cicd-variable-precedence)
+of all types of variables.
+
+## Using cron to trigger nightly pipelines
+
+Whether you craft a script or just run cURL directly, you can trigger jobs
+in conjunction with cron. The example below triggers a job on the `main` branch
+of project with ID `9` every night at `00:30`:
+
+```shell
+30 0 * * * curl --request POST --form token=TOKEN --form ref=main "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
+```
+
+This behavior can also be achieved through the GitLab UI with
+[pipeline schedules](../pipelines/schedules.md).
+
+## Legacy triggers
+
+Old triggers, created before GitLab 9.0 are marked as legacy.
+
+Triggers with the legacy label do not have an associated user and only have
+access to the current project. They are considered deprecated and might be
+removed with one of the future versions of GitLab.
+
+## Troubleshooting
+
+### '404 not found' when triggering a pipeline
+
+A response of `{"message":"404 Not Found"}` when triggering a pipeline might be caused
+by using a Personal Access Token instead of a trigger token. [Add a new trigger](#adding-a-new-trigger)
+and use that token to authenticate when triggering a pipeline.
diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md
index bbbda7815d0..d3de1e6b88a 100644
--- a/doc/ci/troubleshooting.md
+++ b/doc/ci/troubleshooting.md
@@ -52,8 +52,8 @@ and check if their values are what you expect.
 The [complete `gitlab-ci.yml` reference](yaml/README.md) contains a full list of
 every keyword you may need to use to configure your pipelines.
 
-You can also look at a large number of pipeline configuration [examples](examples/README.md)
-and [templates](examples/README.md#cicd-templates).
+You can also look at a large number of pipeline configuration [examples](examples/index.md)
+and [templates](examples/index.md#cicd-templates).
 
 ### Documentation for pipeline types
 
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md
index 872892dbe9b..68980e19399 100644
--- a/doc/ci/variables/README.md
+++ b/doc/ci/variables/README.md
@@ -546,7 +546,7 @@ which variables take precedence.
 
 The order of precedence for variables is (from highest to lowest):
 
-1. [Trigger variables](../triggers/README.md#making-use-of-trigger-variables),
+1. [Trigger variables](../triggers/index.md#making-use-of-trigger-variables),
    [scheduled pipeline variables](../pipelines/schedules.md#using-variables),
    and [manual pipeline run variables](#override-a-variable-when-running-a-pipeline-manually).
 1. Project [variables](#custom-cicd-variables).
@@ -580,7 +580,7 @@ You can override the value of a variable when you:
 1. Create a pipeline by using [the API](../../api/pipelines.md#create-a-new-pipeline).
 1. Run a job manually in the UI.
 1. Use [push options](../../user/project/push_options.md#push-options-for-gitlab-cicd).
-1. Trigger a pipeline by using [the API](../triggers/README.md#making-use-of-trigger-variables).
+1. Trigger a pipeline by using [the API](../triggers/index.md#making-use-of-trigger-variables).
 1. Pass variables to a downstream pipeline [by using the `variable` keyword](../multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword)
    or [by using variable inheritance](../multi_project_pipelines.md#pass-cicd-variables-to-a-downstream-pipeline-by-using-variable-inheritance).
 
diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md
index 4350154634c..1ca40ace13c 100644
--- a/doc/ci/variables/predefined_variables.md
+++ b/doc/ci/variables/predefined_variables.md
@@ -73,8 +73,8 @@ There are also [Kubernetes-specific deployment variables](../../user/project/clu
 | `CI_PAGES_URL`                           | 11.8   | all    | The URL for a GitLab Pages site. Always a subdomain of `CI_PAGES_DOMAIN`. |
 | `CI_PIPELINE_ID`                         | 8.10   | all    | The instance-level ID of the current pipeline. This ID is unique across all projects on the GitLab instance. |
 | `CI_PIPELINE_IID`                        | 11.0   | all    | The project-level IID (internal ID) of the current pipeline. This ID is unique only within the current project. |
-| `CI_PIPELINE_SOURCE`                     | 10.0   | all    | How the pipeline was triggered. Can be `push`, `web`, `schedule`, `api`, `external`, `chat`, `webide`, `merge_request_event`, `external_pull_request_event`, `parent_pipeline`, [`trigger`, or `pipeline`](../triggers/README.md#authentication-tokens). |
-| `CI_PIPELINE_TRIGGERED`                  | all    | all    | `true` if the job was [triggered](../triggers/README.md). |
+| `CI_PIPELINE_SOURCE`                     | 10.0   | all    | How the pipeline was triggered. Can be `push`, `web`, `schedule`, `api`, `external`, `chat`, `webide`, `merge_request_event`, `external_pull_request_event`, `parent_pipeline`, [`trigger`, or `pipeline`](../triggers/index.md#authentication-tokens). |
+| `CI_PIPELINE_TRIGGERED`                  | all    | all    | `true` if the job was [triggered](../triggers/index.md). |
 | `CI_PIPELINE_URL`                        | 11.1   | 0.5    | The URL for the pipeline details. |
 | `CI_PIPELINE_CREATED_AT`                 | 13.10  | all    | The UTC datetime when the pipeline was created, in [ISO 8601](https://tools.ietf.org/html/rfc3339#appendix-A) format. |
 | `CI_PROJECT_CONFIG_PATH`                 | 13.8 to 13.12 | all    | [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/322807) in GitLab 14.0. Use `CI_CONFIG_PATH`. |
@@ -119,7 +119,7 @@ There are also [Kubernetes-specific deployment variables](../../user/project/clu
 | `GITLAB_USER_ID`                         | 8.12   | all    | The ID of the user who started the job. |
 | `GITLAB_USER_LOGIN`                      | 10.0   | all    | The username of the user who started the job. |
 | `GITLAB_USER_NAME`                       | 10.0   | all    | The name of the user who started the job. |
-| `TRIGGER_PAYLOAD`                        | 13.9   | all    | The webhook payload. Only available when a pipeline is [triggered with a webhook](../triggers/README.md#using-webhook-payload-in-the-triggered-pipeline). |
+| `TRIGGER_PAYLOAD`                        | 13.9   | all    | The webhook payload. Only available when a pipeline is [triggered with a webhook](../triggers/index.md#using-webhook-payload-in-the-triggered-pipeline). |
 
 ## Predefined variables for merge request pipelines
 
@@ -130,6 +130,7 @@ These variables are available when:
 
 | Variable                               | GitLab | Runner | Description |
 |----------------------------------------|--------|--------|-------------|
+| `CI_MERGE_REQUEST_APPROVED`            | 14.1   | all    | Approval status of the merge request. `true` when [merge request approvals](../../user/project/merge_requests/approvals/index.md) is available and the merge request has been approved. |
 | `CI_MERGE_REQUEST_ASSIGNEES`           | 11.9   | all    | Comma-separated list of usernames of assignees for the merge request. |
 | `CI_MERGE_REQUEST_ID`                  | 11.6   | all    | The instance-level ID of the merge request. This is a unique ID across all projects on GitLab. |
 | `CI_MERGE_REQUEST_IID`                 | 11.6   | all    | The project-level IID (internal ID) of the merge request. This ID is unique for the current project. |
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 48f735d3bcf..da376ce0daf 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -14,7 +14,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
@@ -369,7 +369,7 @@ workflow:
     - ...                # Previously defined workflow rules here
 ```
 
-[Triggered pipelines](../triggers/README.md) that run on a branch have a `$CI_COMMIT_BRANCH`
+[Triggered pipelines](../triggers/index.md) that run on a branch have a `$CI_COMMIT_BRANCH`
 set and could be blocked by a similar rule. Triggered pipelines have a pipeline source
 of `trigger` or `pipeline`, so `&& $CI_PIPELINE_SOURCE == "push"` ensures the rule
 does not block triggered pipelines.
@@ -1340,7 +1340,7 @@ pipeline based on branch names or pipeline types.
   | `pushes`                 | For pipelines triggered by a `git push` event, including for branches and tags. |
   | `schedules`              | For [scheduled pipelines](../pipelines/schedules.md). |
   | `tags`                   | When the Git reference for a pipeline is a tag. |
-  | `triggers`               | For pipelines created by using a [trigger token](../triggers/README.md#trigger-token). |
+  | `triggers`               | For pipelines created by using a [trigger token](../triggers/index.md#trigger-token). |
   | `web`                    | For pipelines created by using **Run pipeline** button in the GitLab UI, from the project's **CI/CD > Pipelines** section. |
 
 **Example of `only:refs` and `except:refs`**:
@@ -3722,7 +3722,7 @@ with a trigger token.
 
 The trigger token is different than the [`trigger`](#trigger) keyword.
 
-[Read more in the triggers documentation.](../triggers/README.md)
+[Read more in the triggers documentation.](../triggers/index.md)
 
 ### `interruptible`