Merge branch 'docs-rename-readmes-ci' into 'master'

Rename 4 CI README.md files to index.md

See merge request gitlab-org/gitlab!64885

app/assets/javascripts/jobs/components/sidebar_job_details_container.vue

@@ -46,7 +46,7 @@ export default {
       return timeIntervalInWords(this.job.queued);
     },
     runnerHelpUrl() {
-      return helpPagePath('ci/runners/README.html', {
+      return helpPagePath('ci/runners/index.html', {
         anchor: 'set-maximum-job-timeout-for-a-runner',
       });
     },

app/helpers/ci/pipeline_editor_helper.rb

@@ -12,7 +12,7 @@ module Ci
       commit_sha = project.commit ? project.commit.sha : ''
       {
         "ci-config-path": project.ci_config_path_or_default,
-        "ci-examples-help-page-path" => help_page_path('ci/examples/README'),
+        "ci-examples-help-page-path" => help_page_path('ci/examples/index'),
         "ci-help-page-path" => help_page_path('ci/README'),
         "commit-sha" => commit_sha,
         "default-branch" => project.default_branch,
@@ -26,7 +26,7 @@ module Ci
         "project-path" => project.path,
         "project-full-path" => project.full_path,
         "project-namespace" => project.namespace.full_path,
-        "runner-help-page-path" => help_page_path('ci/runners/README'),
+        "runner-help-page-path" => help_page_path('ci/runners/index'),
         "total-branches" => project.repository.branches.length,
         "yml-help-page-path" => help_page_path('ci/yaml/README')
       }

app/views/groups/settings/ci_cd/show.html.haml

@@ -32,7 +32,7 @@
       = expanded ? _('Collapse') : _('Expand')
     %p
       = _("Runners are processes that pick up and execute CI/CD jobs for GitLab.")
-      = link_to s_('How do I configure runners?'), help_page_path('ci/runners/README'), target: '_blank', rel: 'noopener noreferrer'
+      = link_to s_('How do I configure runners?'), help_page_path('ci/runners/index'), target: '_blank', rel: 'noopener noreferrer'
   .settings-content
     = render 'groups/runners/index'
 

app/views/projects/blob/_pipeline_tour_success.html.haml

 .js-success-pipeline-modal{ data: { 'commit-cookie': suggest_pipeline_commit_cookie_name,
   'go-to-pipelines-path': project_pipelines_path(@project),
   'project-merge-requests-path': project_merge_requests_path(@project),
-  'example-link': help_page_path('ci/examples/README.md', anchor: 'gitlab-cicd-examples'),
+  'example-link': help_page_path('ci/examples/index.md', anchor: 'gitlab-cicd-examples'),
   'code-quality-link': help_page_path('user/project/merge_requests/code_quality'),
   'human-access': @project.team.human_max_access(current_user&.id) } }

app/views/projects/settings/ci_cd/show.html.haml

@@ -41,7 +41,7 @@
       = expanded ? _('Collapse') : _('Expand')
     %p
       = _("Runners are processes that pick up and execute CI/CD jobs for GitLab.")
-      = link_to s_('How do I configure runners?'), help_page_path('ci/runners/README'), target: '_blank', rel: 'noopener noreferrer'
+      = link_to s_('How do I configure runners?'), help_page_path('ci/runners/index'), target: '_blank', rel: 'noopener noreferrer'
   .settings-content
     = render 'projects/runners/index'
 
@@ -71,7 +71,7 @@
       = expanded ? _('Collapse') : _('Expand')
     %p
       = _("Trigger a pipeline for a branch or tag by generating a trigger token and using it with an API call. The token impersonates a user's project access and permissions.")
-      = link_to _('Learn more.'), help_page_path('ci/triggers/README'), target: '_blank', rel: 'noopener noreferrer'
+      = link_to _('Learn more.'), help_page_path('ci/triggers/index'), target: '_blank', rel: 'noopener noreferrer'
   .settings-content
     = render 'projects/triggers/index'
 

data/whats_new/202010230001_13_05.yml

@@ -53,7 +53,7 @@
   self-managed: true
   gitlab-com: true
   packages: [Free, Premium, Ultimate]
-  url: https://docs.gitlab.com/ee/ci/runners/README.html#disable-shared-runners
+  url: https://docs.gitlab.com/ee/ci/runners/index.html#disable-shared-runners
   image_url: https://about.gitlab.com/images/13_5/enable_shared_runners_v2.png
   published_at: 2020-10-22
   release: 13.5

doc/administration/pages/index.md

@@ -64,7 +64,7 @@ Before proceeding with the Pages configuration, you must:
 1. Configure a **wildcard DNS record**.
 1. (Optional) Have a **wildcard certificate** for that domain if you decide to
    serve Pages under HTTPS.
-1. (Optional but recommended) Enable [Shared runners](../../ci/runners/README.md)
+1. (Optional but recommended) Enable [Shared runners](../../ci/runners/index.md)
    so that your users don't have to bring their own.
 1. (Only for custom domains) Have a **secondary IP**.
 

doc/administration/pages/source.md

@@ -61,7 +61,7 @@ Before proceeding with the Pages configuration, make sure that:
    Pages artifacts.
 1. (Optional) You have a **wildcard certificate** for the Pages domain if you
    decide to serve Pages (`*.example.io`) under HTTPS.
-1. (Optional but recommended) You have configured and enabled the [shared runners](../../ci/runners/README.md)
+1. (Optional but recommended) You have configured and enabled the [shared runners](../../ci/runners/index.md)
    so that your users don't have to bring their own.
 
 ### DNS configuration

doc/api/README.md

@@ -236,7 +236,7 @@ To make sure that this token doesn't leak, GitLab:
 - Grants permissions to the job token only when the job is running.
 
 To make sure that this token doesn't leak, you should also configure
-your [runners](../ci/runners/README.md) to be secure. Avoid:
+your [runners](../ci/runners/index.md) to be secure. Avoid:
 
 - Using Docker's `privileged` mode if the machines are re-used.
 - Using the [`shell` executor](https://docs.gitlab.com/runner/executors/shell.html) when jobs

doc/api/job_artifacts.md

@@ -20,7 +20,7 @@ GET /projects/:id/jobs/:job_id/artifacts
 |-------------|----------------|----------|--------------------------------------------------------------------------------------------------------------|
 | `id`        | integer/string | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
 | `job_id`    | integer        | yes      | ID of a job.                                                                                                 |
-| `job_token` **(PREMIUM)** | string | no | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
+| `job_token` **(PREMIUM)** | string | no | To be used with [triggers](../ci/triggers/index.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
 
 Example request using the `PRIVATE-TOKEN` header:
 
@@ -85,7 +85,7 @@ Parameters
 | `id`        | integer/string | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
 | `ref_name`  | string         | yes      | Branch or tag name in repository. HEAD or SHA references are not supported.                                  |
 | `job`       | string         | yes      | The name of the job.                                                                                         |
-| `job_token` **(PREMIUM)** | string | no | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
+| `job_token` **(PREMIUM)** | string | no | To be used with [triggers](../ci/triggers/index.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
 
 Example request using the `PRIVATE-TOKEN` header:
 
@@ -146,7 +146,7 @@ Parameters
 | `id`            | integer/string | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
 | `job_id`        | integer        | yes      | The unique job identifier.                                                                                       |
 | `artifact_path` | string         | yes      | Path to a file inside the artifacts archive.                                                                     |
-| `job_token` **(PREMIUM)** | string | no     | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
+| `job_token` **(PREMIUM)** | string | no     | To be used with [triggers](../ci/triggers/index.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
 
 Example request:
 
@@ -188,7 +188,7 @@ Parameters:
 | `ref_name`      | string         | yes      | Branch or tag name in repository. `HEAD` or `SHA` references are not supported.                              |
 | `artifact_path` | string         | yes      | Path to a file inside the artifacts archive.                                                                 |
 | `job`           | string         | yes      | The name of the job.                                                                                         |
-| `job_token` **(PREMIUM)** | string | no     | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
+| `job_token` **(PREMIUM)** | string | no     | To be used with [triggers](../ci/triggers/index.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
 
 Example request:
 

doc/api/pipeline_triggers.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Pipeline triggers API **(FREE)**
 
-You can read more about [triggering pipelines through the API](../ci/triggers/README.md).
+You can read more about [triggering pipelines through the API](../ci/triggers/index.md).
 
 ## List project triggers
 

doc/api/runners.md

@@ -14,7 +14,7 @@ There are two tokens to take into account when connecting a runner with GitLab.
 
 | Token | Description |
 | ----- | ----------- |
-| Registration token   | Token used to [register the runner](https://docs.gitlab.com/runner/register/). It can be [obtained through GitLab](../ci/runners/README.md). |
+| Registration token   | Token used to [register the runner](https://docs.gitlab.com/runner/register/). It can be [obtained through GitLab](../ci/runners/index.md). |
 | Authentication token | Token used to authenticate the runner with the GitLab instance. It is obtained either automatically when [registering a runner](https://docs.gitlab.com/runner/register/), or manually when [registering the runner via the Runner API](#register-a-new-runner). |
 
 Here's an example of how the two tokens are used in runner registration:

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)**
 

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
 

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.

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

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.
 

doc/ci/examples/README.md

 ---
-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 -->

doc/ci/examples/deployment/README.md

 ---
-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 -->

doc/ci/examples/deployment/index.md

+---
+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).

doc/ci/examples/index.md

+---
+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/)

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -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.

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.

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

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.
 

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

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

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.
 

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).

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.

doc/ci/runners/README.md

 ---
-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 -->

doc/ci/runners/index.md

+---
+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.

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

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.

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.

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.

doc/ci/ssh_keys/index.md

@@ -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.

doc/ci/triggers/README.md

 ---
-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 -->

doc/ci/triggers/index.md

+---
+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.

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
 

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).
 

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
 

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`
 

doc/development/cicd/index.md

@@ -61,7 +61,7 @@ successfully or fail. Each status transition for job within a pipeline triggers
 looks for the next jobs to be transitioned towards completion. While doing that, `ProcessPipelineService`
 updates the status of jobs, stages and the overall pipeline.
 
-On the right side of the diagram we have a list of [runners](../../ci/runners/README.md)
+On the right side of the diagram we have a list of [runners](../../ci/runners/index.md)
 connected to the GitLab instance. These can be shared runners, group runners, or project-specific runners.
 The communication between runners and the Rails server occurs through a set of API endpoints, grouped as
 the `Runner API Gateway`.

doc/development/cicd/templates.md

@@ -7,7 +7,7 @@ type: index, concepts, howto
 
 # Development guide for GitLab CI/CD templates
 
-This document explains how to develop [GitLab CI/CD templates](../../ci/examples/README.md).
+This document explains how to develop [GitLab CI/CD templates](../../ci/examples/index.md).
 
 ## Requirements for CI/CD templates
 

doc/development/pipelines.md

@@ -585,7 +585,7 @@ several reasons:
 - It significantly reduces load on the file server, as smaller deltas mean less time spent in `git pack-objects`.
 
 The pre-clone step works by using the `CI_PRE_CLONE_SCRIPT` variable
-[defined by GitLab.com shared runners](../ci/runners/README.md#pre-clone-script).
+[defined by GitLab.com shared runners](../ci/runners/index.md#pre-clone-script).
 
 The `CI_PRE_CLONE_SCRIPT` is currently defined as a project CI/CD variable:
 

doc/raketasks/backup_restore.md

@@ -1192,7 +1192,7 @@ decrypt those columns, preventing access to the following items:
 - [Kubernetes / GCP integration](../user/project/clusters/index.md)
 - [Custom Pages domains](../user/project/pages/custom_domains_ssl_tls_certification/index.md)
 - [Project error tracking](../operations/error_tracking.md)
-- [Runner authentication](../ci/runners/README.md)
+- [Runner authentication](../ci/runners/index.md)
 - [Project mirroring](../user/project/repository/repository_mirroring.md)
 - [Web hooks](../user/project/integrations/webhooks.md)
 

doc/topics/autodevops/quick_start_guide.md

@@ -14,7 +14,7 @@ to create a Kubernetes cluster manually using the Google Cloud Platform console.
 You are creating and deploying a simple application that you create from a GitLab template.
 
 These instructions also work for a self-managed GitLab instance;
-ensure your own [runners are configured](../../ci/runners/README.md) and
+ensure your own [runners are configured](../../ci/runners/index.md) and
 [Google OAuth is enabled](../../integration/google.md).
 
 ## Configure your Google account

doc/topics/cron/index.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Cron syntax is used to schedule when jobs should run.
 
 You may need to use a cron syntax string to
-[trigger nightly pipelines](../../ci/triggers/README.md#using-cron-to-trigger-nightly-pipelines),
+[trigger nightly pipelines](../../ci/triggers/index.md#using-cron-to-trigger-nightly-pipelines),
 create a [pipeline schedule](../../api/pipeline_schedules.md#create-a-new-pipeline-schedule),
 or to prevent unintentional releases by setting a
 [deploy freeze](../../user/project/releases/index.md#prevent-unintentional-releases-by-setting-a-deploy-freeze).

doc/user/admin_area/settings/continuous_integration.md

@@ -224,7 +224,7 @@ This feature is being re-evaluated in favor of a different
 We recommend that users who haven't yet implemented this feature wait for
 the new solution.
 
-You can set a [CI/CD template](../../../ci/examples/README.md#cicd-templates)
+You can set a [CI/CD template](../../../ci/examples/index.md#cicd-templates)
 as a required pipeline configuration for all projects on a GitLab instance. You can
 use a template from:
 

doc/user/application_security/dast/index.md

@@ -50,7 +50,7 @@ results. On failure, the analyzer outputs an
 
 ## Prerequisites
 
-- [GitLab Runner](../../../ci/runners/README.md) available, with the
+- [GitLab Runner](../../../ci/runners/index.md) available, with the
 [`docker` executor](https://docs.gitlab.com/runner/executors/docker.html).
 - Target application deployed. For more details, read [Deployment options](#deployment-options).
 

doc/user/clusters/applications.md

@@ -391,7 +391,7 @@ For GitLab Runner to function, you _must_ specify the following:
 - `gitlabUrl`: The GitLab server full URL (for example, `https://gitlab.example.com`)
   to register the Runner against.
 - `runnerRegistrationToken`: The registration token for adding new runners to GitLab.
-  This must be [retrieved from your GitLab instance](../../ci/runners/README.md).
+  This must be [retrieved from your GitLab instance](../../ci/runners/index.md).
 
 These values can be specified using [CI/CD variables](../../ci/variables/README.md):
 

doc/user/gitlab_com/index.md

@@ -181,7 +181,7 @@ The following limits apply for [Webhooks](../project/integrations/webhooks.md):
 
 GitLab has shared runners on GitLab.com that you can use to run your CI jobs.
 
-For more information, see [choosing a runner](../../ci/runners/README.md).
+For more information, see [choosing a runner](../../ci/runners/index.md).
 
 ## Sidekiq
 

doc/user/group/subgroups/index.md

@@ -125,7 +125,7 @@ When you add a member to a group, that member is also added to all subgroups.
 Permission level is inherited from the group's parent. This model allows access to
 subgroups if you have membership in one of its parents.
 
-Jobs for pipelines in subgroups can use [runners](../../../ci/runners/README.md) registered to the parent group(s).
+Jobs for pipelines in subgroups can use [runners](../../../ci/runners/index.md) registered to the parent group(s).
 This means secrets configured for the parent group are available to subgroup jobs.
 
 In addition, maintainers of projects that belong to subgroups can see the details of runners registered to parent group(s).

doc/user/packages/container_registry/index.md

@@ -154,7 +154,7 @@ To use CI/CD to authenticate, you can use:
   docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
   ```
 
-- A [CI job token](../../../ci/triggers/README.md#ci-job-token).
+- A [CI job token](../../../ci/triggers/index.md#ci-job-token).
 
   ```shell
   docker login -u $CI_JOB_USER -p $CI_JOB_TOKEN $CI_REGISTRY

doc/user/project/deploy_boards.md

@@ -88,7 +88,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/
    [OpenShift docs](https://docs.openshift.com/container-platform/3.7/dev_guide/deployments/kubernetes_deployments.html#kubernetes-deployments-vs-deployment-configurations)
    and [GitLab issue #4584](https://gitlab.com/gitlab-org/gitlab/-/issues/4584).
 
-1. [Configure GitLab Runner](../../ci/runners/README.md) with the [`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
+1. [Configure GitLab Runner](../../ci/runners/index.md) with the [`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
    [`kubernetes`](https://docs.gitlab.com/runner/executors/kubernetes.html) executor.
 1. Configure the [Kubernetes integration](clusters/index.md) in your project for the
    cluster. The Kubernetes namespace is of particular note as you need it

doc/user/project/merge_requests/load_performance_testing.md

@@ -93,7 +93,7 @@ template that is included with GitLab.
 NOTE:
 For large scale k6 tests you need to ensure the GitLab Runner instance performing the actual
 test is able to handle running the test. Refer to [k6's guidance](https://k6.io/docs/testing-guides/running-large-tests#hardware-considerations)
-for spec details. The [default shared GitLab.com runners](../../../ci/runners/README.md#linux-shared-runners)
+for spec details. The [default shared GitLab.com runners](../../../ci/runners/index.md#linux-shared-runners)
 likely have insufficient specs to handle most large k6 tests.
 
 This template runs the

ee/app/assets/javascripts/jobs/components/shared_runner_limit_block.vue

@@ -40,7 +40,7 @@ export default {
       );
     },
     runnersPath() {
-      return helpPagePath('ci/runners/README.html', {
+      return helpPagePath('ci/runners/index.html', {
         anchor: 'set-maximum-job-timeout-for-a-runner',
       });
     },

ee/app/views/namespaces/pipelines_quota/_list.haml

@@ -51,7 +51,7 @@
       %tr
         %td{ colspan: 2 }
           .nothing-here-block
-            - runners_doc_path = help_page_path('ci/runners/README.md')
+            - runners_doc_path = help_page_path('ci/runners/index.md')
             - help_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: runners_doc_path }
             = s_('UsageQuota|%{help_link_start}Shared runners%{help_link_end} are disabled, so there are no limits set on pipeline usage').html_safe % { help_link_start: help_link_start, help_link_end: '</a>'.html_safe }
     - else

spec/frontend/jobs/components/sidebar_detail_row_spec.js

@@ -7,7 +7,7 @@ describe('Sidebar detail row', () => {
 
   const title = 'this is the title';
   const value = 'this is the value';
-  const helpUrl = '/help/ci/runners/README.html';
+  const helpUrl = '/help/ci/runners/index.html';
 
   const findHelpLink = () => wrapper.findComponent(GlLink);
 

spec/helpers/ci/pipeline_editor_helper_spec.rb

@@ -40,7 +40,7 @@ RSpec.describe Ci::PipelineEditorHelper do
       it 'returns pipeline editor data' do
         expect(pipeline_editor_data).to eq({
           "ci-config-path": project.ci_config_path_or_default,
-          "ci-examples-help-page-path" => help_page_path('ci/examples/README'),
+          "ci-examples-help-page-path" => help_page_path('ci/examples/index'),
           "ci-help-page-path" => help_page_path('ci/README'),
           "commit-sha" => project.commit.sha,
           "default-branch" => project.default_branch,
@@ -54,7 +54,7 @@ RSpec.describe Ci::PipelineEditorHelper do
           "project-path" => project.path,
           "project-full-path" => project.full_path,
           "project-namespace" => project.namespace.full_path,
-          "runner-help-page-path" => help_page_path('ci/runners/README'),
+          "runner-help-page-path" => help_page_path('ci/runners/index'),
           "total-branches" => project.repository.branches.length,
           "yml-help-page-path" => help_page_path('ci/yaml/README')
         })
@@ -67,7 +67,7 @@ RSpec.describe Ci::PipelineEditorHelper do
       it 'returns pipeline editor data' do
         expect(pipeline_editor_data).to eq({
           "ci-config-path": project.ci_config_path_or_default,
-          "ci-examples-help-page-path" => help_page_path('ci/examples/README'),
+          "ci-examples-help-page-path" => help_page_path('ci/examples/index'),
           "ci-help-page-path" => help_page_path('ci/README'),
           "commit-sha" => '',
           "default-branch" => project.default_branch,
@@ -81,7 +81,7 @@ RSpec.describe Ci::PipelineEditorHelper do
           "project-path" => project.path,
           "project-full-path" => project.full_path,
           "project-namespace" => project.namespace.full_path,
-          "runner-help-page-path" => help_page_path('ci/runners/README'),
+          "runner-help-page-path" => help_page_path('ci/runners/index'),
           "total-branches" => 0,
           "yml-help-page-path" => help_page_path('ci/yaml/README')
         })