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/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/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/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/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')
         })