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

Rename main CI and variables readme files to index.md

See merge request gitlab-org/gitlab!64886

app/helpers/ci/pipeline_editor_helper.rb

@@ -13,7 +13,7 @@ module Ci
       {
         "ci-config-path": project.ci_config_path_or_default,
         "ci-examples-help-page-path" => help_page_path('ci/examples/index'),
-        "ci-help-page-path" => help_page_path('ci/README'),
+        "ci-help-page-path" => help_page_path('ci/index'),
         "commit-sha" => commit_sha,
         "default-branch" => project.default_branch,
         "empty-state-illustration-path" => image_path('illustrations/empty-state/empty-dag-md.svg'),

app/presenters/dev_ops_report/metric_presenter.rb

@@ -50,7 +50,7 @@ module DevOpsReport
           description: 'created per active user',
           feature: 'ci_pipelines',
           blog: 'https://martinfowler.com/bliki/ContinuousDelivery.html',
-          docs: help_page_path('ci/README')
+          docs: help_page_path('ci/index')
         ),
         Card.new(
           metric: subject,

app/views/admin/application_settings/ci/_header.html.haml

@@ -8,7 +8,7 @@
 
 %p
   = _('Variables store information, like passwords and secret keys, that you can use in job scripts. All projects on the instance can use these variables.')
-  = link_to s_('Learn more.'), help_page_path('ci/variables/README', anchor: 'add-a-cicd-variable-to-an-instance'), target: '_blank', rel: 'noopener noreferrer'
+  = link_to s_('Learn more.'), help_page_path('ci/variables/index', anchor: 'add-a-cicd-variable-to-an-instance'), target: '_blank', rel: 'noopener noreferrer'
 %p
   = _('Variables can be:')
 %ul
@@ -16,4 +16,4 @@
     = html_escape(_('%{code_open}Protected:%{code_close} Only exposed to protected branches or tags.')) % { code_open: '<code>'.html_safe, code_close: '</code>'.html_safe }
   %li
     = html_escape(_('%{code_open}Masked:%{code_close} Hidden in job logs. Must match masking requirements.')) % { code_open: '<code>'.html_safe, code_close: '</code>'.html_safe }
-    = link_to _('Learn more.'), help_page_path('ci/variables/README', anchor: 'mask-a-cicd-variable'), target: '_blank', rel: 'noopener noreferrer'
+    = link_to _('Learn more.'), help_page_path('ci/variables/index', anchor: 'mask-a-cicd-variable'), target: '_blank', rel: 'noopener noreferrer'

app/views/admin/application_settings/ci_cd.html.haml

@@ -8,7 +8,7 @@
   .settings-content
     - if ci_variable_protected_by_default?
       %p.settings-message.text-center
-        - link_start = '<a href="%{url}">'.html_safe % { url: help_page_path('ci/variables/README', anchor: 'protect-a-cicd-variable') }
+        - link_start = '<a href="%{url}">'.html_safe % { url: help_page_path('ci/variables/index', anchor: 'protect-a-cicd-variable') }
         = s_('Environment variables on this GitLab instance are configured to be %{link_start}protected%{link_end} by default.').html_safe % { link_start: link_start, link_end: '</a>'.html_safe }
     #js-instance-variables{ data: { endpoint: admin_ci_variables_path, group: 'true', maskable_regex: ci_variable_maskable_regex, protected_by_default: ci_variable_protected_by_default?.to_s} }
 

app/views/ci/variables/_content.html.haml

 = _('Variables store information, like passwords and secret keys, that you can use in job scripts.')
-= link_to s_('Learn more.'), help_page_path('ci/variables/README'), target: '_blank', rel: 'noopener noreferrer'
+= link_to s_('Learn more.'), help_page_path('ci/variables/index'), target: '_blank', rel: 'noopener noreferrer'
 %p
   = _('Variables can be:')
 %ul
@@ -7,4 +7,4 @@
     = html_escape(_('%{code_open}Protected:%{code_close} Only exposed to protected branches or tags.')) % { code_open: '<code>'.html_safe, code_close: '</code>'.html_safe }
   %li
     = html_escape(_('%{code_open}Masked:%{code_close} Hidden in job logs. Must match masking requirements.')) % { code_open: '<code>'.html_safe, code_close: '</code>'.html_safe }
-    = link_to _('Learn more.'), help_page_path('ci/variables/README', anchor: 'mask-a-cicd-variable'), target: '_blank', rel: 'noopener noreferrer'
+    = link_to _('Learn more.'), help_page_path('ci/variables/index', anchor: 'mask-a-cicd-variable'), target: '_blank', rel: 'noopener noreferrer'

app/views/ci/variables/_index.html.haml

@@ -2,7 +2,7 @@
 
 - if ci_variable_protected_by_default?
   %p.settings-message.text-center
-    - link_start = '<a href="%{url}">'.html_safe % { url: help_page_path('ci/variables/README', anchor: 'protect-a-cicd-variable') }
+    - link_start = '<a href="%{url}">'.html_safe % { url: help_page_path('ci/variables/index', anchor: 'protect-a-cicd-variable') }
     = s_('Environment variables are configured by your administrator to be %{link_start}protected%{link_end} by default.').html_safe % { link_start: link_start, link_end: '</a>'.html_safe }
 
 - is_group = !@group.nil?
@@ -16,8 +16,8 @@
   aws_tip_deploy_link: help_page_path('ci/cloud_deployment/index.md', anchor: 'deploy-your-application-to-the-aws-elastic-container-service-ecs'),
   aws_tip_commands_link: help_page_path('ci/cloud_deployment/index.md', anchor: 'run-aws-commands-from-gitlab-cicd'),
   aws_tip_learn_link: help_page_path('ci/cloud_deployment/index.md', anchor: 'aws'),
-  protected_environment_variables_link: help_page_path('ci/variables/README', anchor: 'protect-a-cicd-variable'),
-  masked_environment_variables_link: help_page_path('ci/variables/README', anchor: 'mask-a-cicd-variable'),
+  protected_environment_variables_link: help_page_path('ci/variables/index', anchor: 'protect-a-cicd-variable'),
+  masked_environment_variables_link: help_page_path('ci/variables/index', anchor: 'mask-a-cicd-variable'),
 } }
 
 - if !@group && @project.group

app/views/ci/variables/_variable_row.html.haml

@@ -39,7 +39,7 @@
         = value
       %p.masking-validation-error.gl-field-error.hide
         = s_("CiVariables|Cannot use Masked Variable with current value")
-        = link_to sprite_icon('question-o'), help_page_path('ci/variables/README', anchor: 'mask-a-cicd-variable'), target: '_blank', rel: 'noopener noreferrer'
+        = link_to sprite_icon('question-o'), help_page_path('ci/variables/index', anchor: 'mask-a-cicd-variable'), target: '_blank', rel: 'noopener noreferrer'
     - unless only_key_value
       .ci-variable-body-item.ci-variable-protected-item.table-section.section-20.mr-0.border-top-0
         .gl-mr-3

doc/administration/server_hooks.md

@@ -34,7 +34,7 @@ Note the following about server hooks:
   administrators are able to complete these tasks. If you don't have file system access, see
   possible alternatives such as:
   - [Webhooks](../user/project/integrations/webhooks.md).
-  - [GitLab CI/CD](../ci/README.md).
+  - [GitLab CI/CD](../ci/index.md).
   - [Push Rules](../push_rules/push_rules.md), for a user-configurable Git hook
     interface.
 - Server hooks aren't replicated to [Geo](geo/index.md) secondary nodes.

doc/api/group_level_variables.md

@@ -89,7 +89,7 @@ POST /groups/:id/variables
 | `variable_type` | string  | no       | The type of a variable. Available types are: `env_var` (default) and `file` |
 | `protected`     | boolean | no       | Whether the variable is protected |
 | `masked`        | boolean | no       | Whether the variable is masked |
-| `environment_scope` **(PREMIUM)** | string | no | The [environment scope](../ci/variables/README.md#limit-the-environment-scope-of-a-cicd-variable) of a variable |
+| `environment_scope` **(PREMIUM)** | string | no | The [environment scope](../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable) of a variable |
 
 ```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
@@ -123,7 +123,7 @@ PUT /groups/:id/variables/:key
 | `variable_type` | string  | no       | The type of a variable. Available types are: `env_var` (default) and `file` |
 | `protected`     | boolean | no       | Whether the variable is protected |
 | `masked`        | boolean | no       | Whether the variable is masked |
-| `environment_scope` **(PREMIUM)** | string | no | The [environment scope](../ci/variables/README.md#limit-the-environment-scope-of-a-cicd-variable) of a variable |
+| `environment_scope` **(PREMIUM)** | string | no | The [environment scope](../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable) of a variable |
 
 ```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" \

doc/ci/chatops/index.md

@@ -25,7 +25,7 @@ with the following arguments:
 - A `<job name>` to execute.
 - The `<job arguments>`.
 
-ChatOps passes the following [CI/CD variables](../variables/README.md#predefined-cicd-variables)
+ChatOps passes the following [CI/CD variables](../variables/index.md#predefined-cicd-variables)
 to the job:
 
 - `CHAT_INPUT` contains any additional arguments.
@@ -55,9 +55,9 @@ functions available. Consider these best practices when creating ChatOps jobs:
 - ChatOps provides limited support for access control. If the user triggering the
   slash command has [Developer access or above](../../user/permissions.md#project-members-permissions)
   in the project, the job runs. The job itself can use existing
-  [CI/CD variables](../variables/README.md#predefined-cicd-variables) like
+  [CI/CD variables](../variables/index.md#predefined-cicd-variables) like
   `GITLAB_USER_ID` to perform additional rights validation, but
-  these variables can be [overridden](../variables/README.md#cicd-variable-precedence).
+  these variables can be [overridden](../variables/index.md#cicd-variable-precedence).
 
 ### Controlling the ChatOps reply
 

doc/ci/cloud_deployment/ecs/quick_start_guide.md

@@ -211,7 +211,7 @@ Do not share the secret access key in a public place. You must save it in a secu
 
 ### Setup credentials in GitLab to let pipeline jobs access to ECS
 
-You can register the access information in [GitLab Environment Variables](../../variables/README.md#custom-cicd-variables).
+You can register the access information in [GitLab Environment Variables](../../variables/index.md#custom-cicd-variables).
 These variables are injected into the pipeline jobs and can access the ECS API.
 
 1. Go to **ecs-demo** project on GitLab.

doc/ci/cloud_deployment/index.md

@@ -43,7 +43,7 @@ Some credentials are required to be able to run `aws` commands:
    A new **Access key ID** and **Secret access key** are generated. Please take a note of them right away.
 
 1. In your GitLab project, go to **Settings > CI/CD**. Set the following as
-   [CI/CD variables](../variables/README.md)
+   [CI/CD variables](../variables/index.md)
    (see table below):
 
    - Access key ID.
@@ -117,7 +117,7 @@ After you have these prerequisites ready, follow these steps:
 1. Make sure your AWS credentials are set up as CI/CD variables for your
    project. You can follow [the steps above](#run-aws-commands-from-gitlab-cicd) to complete this setup.
 1. Add these variables to your project's `.gitlab-ci.yml` file, or in the project's
-   [CI/CD settings](../variables/README.md#custom-cicd-variables):
+   [CI/CD settings](../variables/index.md#custom-cicd-variables):
 
    - `CI_AWS_ECS_CLUSTER`: The name of the AWS ECS cluster that you're targeting for your deployments.
    - `CI_AWS_ECS_SERVICE`: The name of the targeted service tied to your AWS ECS cluster.
@@ -146,7 +146,7 @@ After you have these prerequisites ready, follow these steps:
    ```
 
    You can create your `CI_AWS_ECS_TASK_DEFINITION_FILE` variable as a
-   [file-typed CI/CD variable](../variables/README.md#cicd-variable-types) instead of a
+   [file-typed CI/CD variable](../variables/index.md#cicd-variable-types) instead of a
    regular CI/CD variable. If you choose to do so, set the variable value to be the full contents of
    the JSON task definition. You can then remove the JSON file from your project.
 
@@ -257,7 +257,7 @@ pass three JSON input objects, based on existing templates:
        CI_AWS_EC2_DEPLOYMENT_FILE: 'aws/create_deployment.json'
      ```
 
-   - Alternatively, you can provide these JSON objects as [file-typed CI/CD variables](../variables/README.md#cicd-variable-types).
+   - Alternatively, you can provide these JSON objects as [file-typed CI/CD variables](../variables/index.md#cicd-variable-types).
      In your project, go to **Settings > CI/CD > Variables** and add
      the three variables listed above as file-typed CI/CD variables.
      For each variable, set the value to its corresponding JSON object.

doc/ci/docker/using_docker_images.md

@@ -225,7 +225,7 @@ To access private container registries, the GitLab Runner process can use:
 To define which option should be used, the runner process reads the configuration in this order:
 
 - A `DOCKER_AUTH_CONFIG` variable provided as either:
-  - A [CI/CD variable](../variables/README.md) in the `.gitlab-ci.yml` file.
+  - A [CI/CD variable](../variables/index.md) in the `.gitlab-ci.yml` file.
   - A project's variables stored on the project's **Settings > CI/CD** page.
 - A `DOCKER_AUTH_CONFIG` variable provided as environment variable in the runner's `config.toml` file.
 - A `config.json` file in `$HOME/.docker` directory of the user running the process.
@@ -322,7 +322,7 @@ Use one of the following methods to determine the value of `DOCKER_AUTH_CONFIG`:
 To configure a single job with access for `registry.example.com:5000`,
 follow these steps:
 
-1. Create a [CI/CD variable](../variables/README.md) `DOCKER_AUTH_CONFIG` with the content of the
+1. Create a [CI/CD variable](../variables/index.md) `DOCKER_AUTH_CONFIG` with the content of the
    Docker configuration file as the value:
 
    ```json
@@ -395,7 +395,7 @@ To configure a Credentials Store:
 1. Make GitLab Runner use it. There are two ways to accomplish this. Either:
 
    - Create a
-     [CI/CD variable](../variables/README.md)
+     [CI/CD variable](../variables/index.md)
      `DOCKER_AUTH_CONFIG` with the content of the
      Docker configuration file as the value:
 
@@ -427,7 +427,7 @@ To configure access for `aws_account_id.dkr.ecr.region.amazonaws.com`, follow th
    Make sure that GitLab Runner can access the credentials.
 1. Make GitLab Runner use it. There are two ways to accomplish this. Either:
 
-   - Create a [CI/CD variable](../variables/README.md)
+   - Create a [CI/CD variable](../variables/index.md)
      `DOCKER_AUTH_CONFIG` with the content of the
      Docker configuration file as the value:
 

doc/ci/docker/using_kaniko.md

@@ -49,7 +49,7 @@ In the following example, kaniko is used to:
 
 The job runs only when a tag is pushed. A `config.json` file is created under
 `/kaniko/.docker` with the needed GitLab Container Registry credentials taken from the
-[predefined CI/CD variables](../variables/README.md#predefined-cicd-variables)
+[predefined CI/CD variables](../variables/index.md#predefined-cicd-variables)
 GitLab CI/CD provides.
 
 In the last step, kaniko uses the `Dockerfile` under the

doc/ci/environments/deployment_safety.md

@@ -110,7 +110,7 @@ for an explanation of these roles and the permissions of each.
 
 Production secrets are needed to deploy successfully. For example, when deploying to the cloud,
 cloud providers require these secrets to connect to their services. In the project settings, you can
-define and protect CI/CD variables for these secrets. [Protected variables](../variables/README.md#protect-a-cicd-variable)
+define and protect CI/CD variables for these secrets. [Protected variables](../variables/index.md#protect-a-cicd-variable)
 are only passed to pipelines running on [protected branches](../../user/project/protected_branches.md)
 or [protected tags](../../user/project/protected_tags.md).
 The other pipelines don't get the protected variable. You can also

doc/ci/environments/index.md

@@ -691,7 +691,7 @@ with `review/` would have that variable available.
 
 Some GitLab features can behave differently for each environment.
 For example, you can
-[create a project CI/CD variable to be injected only into a production environment](../variables/README.md#limit-the-environment-scope-of-a-cicd-variable).
+[create a project CI/CD variable to be injected only into a production environment](../variables/index.md#limit-the-environment-scope-of-a-cicd-variable).
 
 In most cases, these features use the _environment specs_ mechanism, which offers
 an efficient way to implement scoping in each environment group.

doc/ci/examples/deployment/index.md

@@ -128,4 +128,4 @@ 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).
+Read more about the [CI/CD variables](../../variables/index.md).

doc/ci/examples/end_to_end_testing_webdriverio/index.md

@@ -191,7 +191,7 @@ option as an argument to `npm run confidence-check` on the command line.
 However, we still need to tell WebdriverIO which browser is available for it to use.
 
 [GitLab CI/CD makes
-a number of variables available](../../variables/README.md#predefined-cicd-variables)
+a number of variables available](../../variables/index.md#predefined-cicd-variables)
 with information about the current CI job. We can use this information to dynamically set
 up our WebdriverIO configuration according to the job that is running. More specifically, we can
 tell WebdriverIO what browser to execute the test on depending on the name of the currently running

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -119,7 +119,7 @@ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
 cat ~/.ssh/id_rsa
 ```
 
-Now, let's add it to your GitLab project as a [CI/CD variable](../../variables/README.md).
+Now, let's add it to your GitLab project as a [CI/CD variable](../../variables/index.md).
 Project CI/CD variables are user-defined variables and are stored out of `.gitlab-ci.yml`, for security purposes.
 They can be added per project by navigating to the project's **Settings** > **CI/CD**.
 

doc/ci/jobs/index.md

@@ -157,9 +157,9 @@ additional variables. To access this page, click on the **name** of the manual j
 the pipeline view, *not* the play (**{play}**) button.
 
 This is useful when you want to alter the execution of a job that uses
-[custom CI/CD variables](../variables/README.md#custom-cicd-variables).
+[custom CI/CD variables](../variables/index.md#custom-cicd-variables).
 Add a variable name (key) and value here to override the value defined in
-[the UI or `.gitlab-ci.yml`](../variables/README.md#custom-cicd-variables),
+[the UI or `.gitlab-ci.yml`](../variables/index.md#custom-cicd-variables),
 for a single run of the manual job.
 
 ![Manual job variables](img/manual_job_variables_v13_10.png)

doc/ci/jobs/job_control.md

@@ -263,7 +263,7 @@ Other commonly used variables for `if` clauses:
   branch. Use when you want to have the same configuration in multiple
   projects with different default branches.
 - `if: '$CI_COMMIT_BRANCH =~ /regex-expression/'`: If the commit branch matches a regular expression.
-- `if: '$CUSTOM_VARIABLE !~ /regex-expression/'`: If the [custom variable](../variables/README.md#custom-cicd-variables)
+- `if: '$CUSTOM_VARIABLE !~ /regex-expression/'`: If the [custom variable](../variables/index.md#custom-cicd-variables)
   `CUSTOM_VARIABLE` does **not** match a regular expression.
 - `if: '$CUSTOM_VARIABLE == "value1"'`: If the custom variable `CUSTOM_VARIABLE` is
   exactly `value1`.

doc/ci/migration/circleci.md

@@ -265,7 +265,7 @@ test_async:
 
 ## Contexts and variables
 
-CircleCI provides [Contexts](https://circleci.com/docs/2.0/contexts/) to securely pass environment variables across project pipelines. In GitLab, a [Group](../../user/group/index.md) can be created to assemble related projects together. At the group level, [CI/CD variables](../variables/README.md#add-a-cicd-variable-to-a-group) can be stored outside the individual projects, and securely passed into pipelines across multiple projects.
+CircleCI provides [Contexts](https://circleci.com/docs/2.0/contexts/) to securely pass environment variables across project pipelines. In GitLab, a [Group](../../user/group/index.md) can be created to assemble related projects together. At the group level, [CI/CD variables](../variables/index.md#add-a-cicd-variable-to-a-group) can be stored outside the individual projects, and securely passed into pipelines across multiple projects.
 
 ## Orbs
 

doc/ci/migration/jenkins.md

@@ -199,7 +199,7 @@ GitLab takes advantage of our connected ecosystem to automatically pull these ki
 your Merge Requests, pipeline details pages, and other locations. You may find that you actually don't
 need to configure anything to have these appear.
 
-If they aren't working as expected, or if you'd like to see what's available, our [CI feature index](../README.md#feature-set) has the full list
+If they aren't working as expected, or if you'd like to see what's available, our [CI feature index](../index.md#feature-set) has the full list
 of bundled features and links to the documentation for each.
 
 ### Templates
@@ -304,8 +304,8 @@ my_job:
 #### `environment`
 
 In GitLab, we use the [`variables` keyword](../yaml/README.md#variables) to define different variables at runtime.
-These can also be set up through the GitLab UI, under CI/CD settings. See also our [general documentation on variables](../variables/README.md),
-including the section on [protected variables](../variables/README.md#protect-a-cicd-variable) which can be used
+These can also be set up through the GitLab UI, under CI/CD settings. See also our [general documentation on variables](../variables/index.md),
+including the section on [protected variables](../variables/index.md#protect-a-cicd-variable) which can be used
 to limit access to certain variables to certain environments or runners:
 
 ```yaml

doc/ci/multi_project_pipelines.md

@@ -9,7 +9,7 @@ type: reference
 
 > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
 
-You can set up [GitLab CI/CD](README.md) across multiple projects, so that a pipeline
+You can set up [GitLab CI/CD](index.md) across multiple projects, so that a pipeline
 in one project can trigger a pipeline in another project. You can visualize the entire pipeline
 in one place, including all cross-project interdependencies.
 
@@ -175,7 +175,7 @@ the ones defined in the upstream project take precedence.
 
 #### Pass CI/CD variables to a downstream pipeline by using variable inheritance
 
-You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/README.md#pass-an-environment-variable-to-another-job) and [cross project artifact downloads](yaml/README.md#cross-project-artifact-downloads-with-needs).
+You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/index.md#pass-an-environment-variable-to-another-job) and [cross project artifact downloads](yaml/README.md#cross-project-artifact-downloads-with-needs).
 
 In the upstream pipeline:
 

doc/ci/pipelines/index.md

@@ -75,7 +75,7 @@ You can also configure specific aspects of your pipelines through the GitLab UI.
 
 - [Pipeline settings](settings.md) for each project.
 - [Pipeline schedules](schedules.md).
-- [Custom CI/CD variables](../variables/README.md#custom-cicd-variables).
+- [Custom CI/CD variables](../variables/index.md#custom-cicd-variables).
 
 ### Ref Specs for Runners
 
@@ -125,7 +125,7 @@ you can filter the pipeline list by:
 
 ### Run a pipeline manually
 
-Pipelines can be manually executed, with predefined or manually-specified [variables](../variables/README.md).
+Pipelines can be manually executed, with predefined or manually-specified [variables](../variables/index.md).
 
 You might do this if the results of a pipeline (for example, a code build) are required outside the normal
 operation of the pipeline.
@@ -136,7 +136,7 @@ To execute a pipeline manually:
 1. Select the **Run pipeline** button.
 1. On the **Run pipeline** page:
     1. Select the branch or tag to run the pipeline for in the **Run for branch name or tag** field.
-    1. Enter any [environment variables](../variables/README.md) required for the pipeline run.
+    1. Enter any [environment variables](../variables/index.md) required for the pipeline run.
        You can set specific variables to have their [values prefilled in the form](#prefill-variables-in-manual-pipelines).
     1. Click the **Run pipeline** button.
 
@@ -148,7 +148,7 @@ The pipeline now executes the jobs as configured.
 
 You can use the [`value` and `description`](../yaml/README.md#prefill-variables-in-manual-pipelines)
 keywords to define
-[pipeline-level (global) variables](../variables/README.md#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file)
+[pipeline-level (global) variables](../variables/index.md#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file)
 that are prefilled when running a pipeline manually.
 
 In pipelines triggered manually, the **Run pipelines** page displays all top-level variables

doc/ci/pipelines/job_artifacts.md

@@ -203,5 +203,5 @@ This message is often preceded by other errors or warnings that specify the file
 generated. Check the job log for these messages.
 
 If you find no helpful messages, retry the failed job after activating
-[CI/CD debug logging](../variables/README.md#debug-logging).
+[CI/CD debug logging](../variables/index.md#debug-logging).
 This logging should provide information to help you investigate further.

doc/ci/review_apps/index.md

@@ -62,7 +62,7 @@ The process of configuring Review Apps is as follows:
 
 1. Set up the infrastructure to host and deploy the Review Apps (check the [examples](#review-apps-examples) below).
 1. [Install](https://docs.gitlab.com/runner/install/) and [configure](https://docs.gitlab.com/runner/commands/) a runner to do deployment.
-1. Set up a job in `.gitlab-ci.yml` that uses the [predefined CI/CD variable](../variables/README.md) `${CI_COMMIT_REF_NAME}`
+1. Set up a job in `.gitlab-ci.yml` that uses the [predefined CI/CD variable](../variables/index.md) `${CI_COMMIT_REF_NAME}`
    to create dynamic environments and restrict it to run only on branches.
    Alternatively, you can get a YML template for this job by [enabling review apps](#enable-review-apps-button) for your project.
 1. Optionally, set a job that [manually stops](../environments/index.md#stopping-an-environment) the Review Apps.

doc/ci/runners/configure_runners.md

@@ -230,7 +230,7 @@ Example 2:
 
 ## Configure runner behavior with variables
 
-You can use [CI/CD variables](../variables/README.md) to configure runner Git behavior
+You can use [CI/CD variables](../variables/index.md) to configure runner Git behavior
 globally or for individual jobs:
 
 - [`GIT_STRATEGY`](#git-strategy)

doc/ci/runners/index.md

@@ -58,7 +58,7 @@ can be used for:
 - 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
+To use this feature, define a [CI/CD variable](../../ci/variables/index.md#custom-cicd-variables) called
 `CI_PRE_CLONE_SCRIPT` that contains a bash script.
 
 [This example](../../development/pipelines.md#pre-clone-step)

doc/ci/secrets/index.md

@@ -80,7 +80,7 @@ To configure your Vault server:
 
 1. Configure roles on your Vault server, restricting roles to a project or namespace,
    as described in [Configure Vault server roles](#configure-vault-server-roles) on this page.
-1. [Create the following CI/CD variables](../variables/README.md#custom-cicd-variables)
+1. [Create the following CI/CD variables](../variables/index.md#custom-cicd-variables)
    to provide details about your Vault server:
    - `VAULT_SERVER_URL` - The URL of your Vault server, such as `https://vault.example.com:8200`.
      Required.
@@ -114,7 +114,7 @@ In this example:
 
 After GitLab fetches the secret from Vault, the value is saved in a temporary file.
 The path to this file is stored in a CI/CD variable named `DATABASE_PASSWORD`,
-similar to [variables of type `file`](../variables/README.md#cicd-variable-types).
+similar to [variables of type `file`](../variables/index.md#cicd-variable-types).
 
 For more information about the supported syntax, read the
 [`.gitlab-ci.yml` reference](../yaml/README.md#secretsvault).

doc/ci/services/gitlab.md

@@ -25,7 +25,7 @@ tests access to the GitLab API.
    ```
 
 1. To set values for the `GITLAB_HTTPS` and `GITLAB_ROOT_PASSWORD`,
-   [assign them to a variable in the user interface](../variables/README.md#add-a-cicd-variable-to-a-project).
+   [assign them to a variable in the user interface](../variables/index.md#add-a-cicd-variable-to-a-project).
    Then assign that variable to the corresponding variable in your
    `.gitlab-ci.yml` file.
 

doc/ci/services/index.md

@@ -188,9 +188,9 @@ To override the default behavior, you can
 
 ## Passing CI/CD variables to services
 
-You can also pass custom CI/CD [variables](../variables/README.md)
+You can also pass custom CI/CD [variables](../variables/index.md)
 to fine tune your Docker `images` and `services` directly in the `.gitlab-ci.yml` file.
-For more information, read about [`.gitlab-ci.yml` defined variables](../variables/README.md#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file).
+For more information, read about [`.gitlab-ci.yml` defined variables](../variables/index.md#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file).
 
 ```yaml
 # The following variables are automatically passed down to the Postgres container

doc/ci/services/mysql.md

@@ -16,7 +16,7 @@ If you want to use a MySQL container, you can use [GitLab Runner](../runners/ind
 
 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`.
 
-1. [Create CI/CD variables](../variables/README.md#custom-cicd-variables) for your
+1. [Create CI/CD variables](../variables/index.md#custom-cicd-variables) for your
    MySQL database and password by going to **Settings > CI/CD**, expanding **Variables**,
    and clicking **Add Variable**.
 

doc/ci/services/postgres.md

@@ -31,7 +31,7 @@ variables:
 
 To set values for the `POSTGRES_DB`, `POSTGRES_USER`,
 `POSTGRES_PASSWORD` and `POSTGRES_HOST_AUTH_METHOD`,
-[assign them to a CI/CD variable in the user interface](../variables/README.md#custom-cicd-variables),
+[assign them to a CI/CD variable in the user interface](../variables/index.md#custom-cicd-variables),
 then assign that variable to the corresponding variable in your
 `.gitlab-ci.yml` file.
 

doc/ci/ssh_keys/index.md

@@ -28,7 +28,7 @@ with any type of [executor](https://docs.gitlab.com/runner/executors/)
 ## How it works
 
 1. Create a new SSH key pair locally with [`ssh-keygen`](https://linux.die.net/man/1/ssh-keygen)
-1. Add the private key as a [variable](../variables/README.md) to
+1. Add the private key as a [variable](../variables/index.md) to
    your project
 1. Run the [`ssh-agent`](https://linux.die.net/man/1/ssh-agent) during job to load
    the private key.
@@ -38,7 +38,7 @@ with any type of [executor](https://docs.gitlab.com/runner/executors/)
 
 In the following example, the `ssh-add -` command does not display the value of
 `$SSH_PRIVATE_KEY` in the job log, though it could be exposed if you enable
-[debug logging](../variables/README.md#debug-logging). You might also want to
+[debug logging](../variables/index.md#debug-logging). You might also want to
 check the [visibility of your pipelines](../pipelines/settings.md#visibility-of-pipelines).
 
 ## SSH keys when using the Docker executor
@@ -52,7 +52,7 @@ to access it. This is where an SSH key pair comes in handy.
    **Do not** add a passphrase to the SSH key, or the `before_script` will
    prompt for it.
 
-1. Create a new [CI/CD variable](../variables/README.md).
+1. Create a new [CI/CD variable](../variables/index.md).
    As **Key** enter the name `SSH_PRIVATE_KEY` and in the **Value** field paste
    the content of your _private_ key that you created earlier.
 
@@ -160,7 +160,7 @@ ssh-keyscan example.com
 ssh-keyscan 1.2.3.4
 ```
 
-Create a new [CI/CD variable](../variables/README.md) with
+Create a new [CI/CD variable](../variables/index.md) with
 `SSH_KNOWN_HOSTS` as "Key", and as a "Value" add the output of `ssh-keyscan`.
 
 If you need to connect to multiple servers, all the server host keys

doc/ci/triggers/index.md

@@ -35,12 +35,12 @@ A unique trigger token can be obtained when [adding a new trigger](#adding-a-new
 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)
+their `.gitlab-ci.yml` file. Use [CI/CD variables](../variables/index.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
+You can use the `CI_JOB_TOKEN` [CI/CD variable](../variables/index.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
@@ -192,7 +192,7 @@ source repository. Be sure to URL-encode `ref` if it contains slashes.
 
 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),
+The payload is exposed as a [file-type variable](../variables/index.md#cicd-variable-types),
 so you can access the data with `cat $TRIGGER_PAYLOAD` or a similar command.
 
 ## Making use of trigger variables
@@ -255,7 +255,7 @@ curl --request POST \
   "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
 ```
 
-Trigger variables have the [highest priority](../variables/README.md#cicd-variable-precedence)
+Trigger variables have the [highest priority](../variables/index.md#cicd-variable-precedence)
 of all types of variables.
 
 ## Using cron to trigger nightly pipelines

doc/ci/troubleshooting.md

@@ -43,7 +43,7 @@ pipeline, and what their values are. A lot of pipeline configuration is dependen
 on variables, and verifying them is one of the fastest ways to find the source of
 a problem.
 
-[Export the full list of variables](variables/README.md#list-all-environment-variables)
+[Export the full list of variables](variables/index.md#list-all-environment-variables)
 available in each problematic job. Check if the variables you expect are present,
 and check if their values are what you expect.
 

doc/ci/variables/predefined_variables.md

@@ -7,11 +7,11 @@ type: reference
 
 # Predefined variables reference **(FREE)**
 
-Predefined [CI/CD variables](README.md) are available in every GitLab CI/CD pipeline.
+Predefined [CI/CD variables](index.md) are available in every GitLab CI/CD pipeline.
 
 Some variables are only available with more recent versions of [GitLab Runner](https://docs.gitlab.com/runner/).
 
-You can [output the values of all variables available for a job](README.md#list-all-environment-variables)
+You can [output the values of all variables available for a job](index.md#list-all-environment-variables)
 with a `script` command.
 
 There are also [Kubernetes-specific deployment variables](../../user/project/clusters/deploy_to_cluster.md#deployment-variables).
@@ -39,7 +39,7 @@ There are also [Kubernetes-specific deployment variables](../../user/project/clu
 | `CI_CONCURRENT_ID`                       | all    | 11.10  | The unique ID of build execution in a single executor. |
 | `CI_CONCURRENT_PROJECT_ID`               | all    | 11.10  | The unique ID of build execution in a single executor and project. |
 | `CI_CONFIG_PATH`                         | 9.4    | 0.5    | The path to the CI/CD configuration file. Defaults to `.gitlab-ci.yml`. |
-| `CI_DEBUG_TRACE`                         | all    | 1.7    | `true` if [debug logging (tracing)](README.md#debug-logging) is enabled. |
+| `CI_DEBUG_TRACE`                         | all    | 1.7    | `true` if [debug logging (tracing)](index.md#debug-logging) is enabled. |
 | `CI_DEFAULT_BRANCH`                      | 12.4   | all    | The name of the project's default branch. |
 | `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX` | 13.7   | all    | The image prefix for pulling images through the Dependency Proxy. |
 | `CI_DEPENDENCY_PROXY_PASSWORD`           | 13.7   | all    | The password to pull images through the Dependency Proxy. |

doc/ci/variables/where_variables_can_be_used.md

@@ -7,7 +7,7 @@ type: reference
 
 # Where variables can be used
 
-As it's described in the [CI/CD variables](README.md) docs, you can
+As it's described in the [CI/CD variables](index.md) docs, you can
 define many different variables. Some of them can be used for all GitLab CI/CD
 features, but some of them are more or less limited.
 

doc/ci/yaml/README.md

@@ -1122,7 +1122,7 @@ Use `rules:if` clauses to specify when to add a job to a pipeline:
 - If no `if` statements are true, do not add the job to the pipeline.
 
 `if:` clauses are evaluated based on the values of [predefined CI/CD variables](../variables/predefined_variables.md)
-or [custom CI/CD variables](../variables/README.md#custom-cicd-variables).
+or [custom CI/CD variables](../variables/index.md#custom-cicd-variables).
 
 **Keyword type**: Job-specific and pipeline-specific. You can use it as part of a job
 to configure the job behavior, or with [`workflow`](#workflow) to configure the pipeline behavior.
@@ -1149,7 +1149,7 @@ job:
   defined for the job, which defaults to `on_success` if not defined.
 - You can define `when` once per rule, or once at the job-level, which applies to
   all rules. You can't mix `when` at the job-level with `when` in rules.
-- Unlike variables in [`script`](../variables/README.md#use-cicd-variables-in-job-scripts)
+- Unlike variables in [`script`](../variables/index.md#use-cicd-variables-in-job-scripts)
   sections, variables in rules expressions are always formatted as `$VARIABLE`.
 
 **Related topics**:
@@ -1402,7 +1402,7 @@ job2:
 #### `only:variables` / `except:variables`
 
 Use the `only:variables` or `except:variables` keywords to control when to add jobs
-to a pipeline, based on the status of [CI/CD variables](../variables/README.md).
+to a pipeline, based on the status of [CI/CD variables](../variables/index.md).
 
 **Keyword type**: Job keyword. You can use it only as part of a job.
 
@@ -2303,7 +2303,7 @@ see [Deployment tier of environments](../environments/index.md#deployment-tier-o
 
 #### Dynamic environments
 
-Use CI/CD [variables](../variables/README.md) to dynamically name environments.
+Use CI/CD [variables](../variables/index.md) to dynamically name environments.
 
 For example:
 
@@ -2318,7 +2318,7 @@ deploy as review app:
 
 The `deploy as review app` job is marked as a deployment to dynamically
 create the `review/$CI_COMMIT_REF_NAME` environment. `$CI_COMMIT_REF_NAME`
-is a [CI/CD variable](../variables/README.md) set by the runner. The
+is a [CI/CD variable](../variables/index.md) set by the runner. The
 `$CI_ENVIRONMENT_SLUG` variable is based on the environment name, but suitable
 for inclusion in URLs. If the `deploy as review app` job runs in a branch named
 `pow`, this environment would be accessible with a URL like `https://review-pow.example.com/`.
@@ -2384,7 +2384,7 @@ no `cache:key` share the `default` cache.
 **Possible inputs**:
 
 - A string.
-- A [predefined variables](../variables/README.md).
+- A [predefined variables](../variables/index.md).
 - A combination of both.
 
 **Example of `cache:key`**:
@@ -2469,7 +2469,7 @@ Use `cache:key:prefix` to combine a prefix with the SHA computed for [`cache:key
 **Possible inputs**:
 
 - A string
-- A [predefined variables](../variables/README.md)
+- A [predefined variables](../variables/index.md)
 - A combination of both.
 
 **Example of `cache:key:prefix`**:
@@ -2830,7 +2830,7 @@ Note the following:
 
 Use the `name` directive to define the name of the created artifacts
 archive. You can specify a unique name for every archive. The `artifacts:name`
-variable can make use of any of the [predefined variables](../variables/README.md).
+variable can make use of any of the [predefined variables](../variables/index.md).
 The default name is `artifacts`, which becomes `artifacts.zip` when you download it.
 
 To create an archive with a name of the current job:
@@ -3426,7 +3426,7 @@ test:
 ```
 
 Every parallel job has a `CI_NODE_INDEX` and `CI_NODE_TOTAL`
-[predefined CI/CD variable](../variables/README.md#predefined-cicd-variables) set.
+[predefined CI/CD variable](../variables/index.md#predefined-cicd-variables) set.
 
 Different languages and test suites have different methods to enable parallelization.
 For example, use [Semaphore Test Boosters](https://github.com/renderedtext/test-boosters)
@@ -3465,7 +3465,7 @@ There can be from 2 to 50 jobs.
 Jobs can only run in parallel if there are multiple runners, or a single runner is
 [configured to run multiple jobs concurrently](#use-your-own-runners).
 
-Every job gets the same `CI_NODE_TOTAL` [CI/CD variable](../variables/README.md#predefined-cicd-variables) value, and a unique `CI_NODE_INDEX` value.
+Every job gets the same `CI_NODE_TOTAL` [CI/CD variable](../variables/index.md#predefined-cicd-variables) value, and a unique `CI_NODE_INDEX` value.
 
 ```yaml
 deploystacks:
@@ -3981,7 +3981,7 @@ release:
 ```
 
 The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a
-[custom variable in the UI](../variables/README.md#custom-cicd-variables),
+[custom variable in the UI](../variables/index.md#custom-cicd-variables),
 either as a `file`, which requires the path to the certificate, or as a variable,
 which requires the text representation of the certificate.
 
@@ -4383,12 +4383,12 @@ karma:
 
 > Introduced in GitLab Runner v0.5.0.
 
-[CI/CD variables](../variables/README.md) are configurable values that are passed to jobs.
+[CI/CD variables](../variables/index.md) are configurable values that are passed to jobs.
 They can be set globally and per-job.
 
 There are two types of variables.
 
-- [Custom variables](../variables/README.md#custom-cicd-variables):
+- [Custom variables](../variables/index.md#custom-cicd-variables):
   You can define their values in the `.gitlab-ci.yml` file, in the GitLab UI,
   or by using the API. You can also input variables in the GitLab UI when
   [running a pipeline manually](../pipelines/index.md#run-a-pipeline-manually).
@@ -4424,7 +4424,7 @@ meaning it applies to all jobs. If you define a variable in a job, it's availabl
 to that job only.
 
 If a variable of the same name is defined globally and for a specific job, the
-[job-specific variable overrides the global variable](../variables/README.md#cicd-variable-precedence).
+[job-specific variable overrides the global variable](../variables/index.md#cicd-variable-precedence).
 
 All YAML-defined variables are also set to any linked
 [Docker service containers](../services/index.md).
@@ -4449,7 +4449,7 @@ You cannot set job-level variables to be pre-filled when you run a pipeline manu
 
 ### Configure runner behavior with variables
 
-You can use [CI/CD variables](../variables/README.md) to configure how the runner processes Git requests:
+You can use [CI/CD variables](../variables/index.md) to configure how the runner processes Git requests:
 
 - [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy)
 - [`GIT_SUBMODULE_STRATEGY`](../runners/configure_runners.md#git-submodule-strategy)

doc/ci/yaml/script.md

@@ -121,7 +121,7 @@ job:
     - echo -e "\e[31mThis text is red,\e[0m but this text isn't\e[31m however this text is red again."
 ```
 
-You can define the color codes in Shell environment variables, or even [custom CI/CD variables](../variables/README.md#custom-cicd-variables),
+You can define the color codes in Shell environment variables, or even [custom CI/CD variables](../variables/index.md#custom-cicd-variables),
 which makes the commands easier to read and reusable.
 
 For example, using the same example as above and environment variables defined in a `before_script`:

doc/development/dangerbot.md

@@ -153,10 +153,10 @@ at GitLab so far:
 Danger is run but its output is not added to a merge request comment if working
 on a fork. This happens because the secret variable from the canonical project
 is not shared to forks. To work around this, you can add an [environment
-variable](../ci/variables/README.md) called `DANGER_GITLAB_API_TOKEN` with a
+variable](../ci/variables/index.md) called `DANGER_GITLAB_API_TOKEN` with a
 personal API token to your fork. That way the danger comments are made from CI
 using that API token instead. Making the variable
-[masked](../ci/variables/README.md#mask-a-cicd-variable) makes sure it
+[masked](../ci/variables/index.md#mask-a-cicd-variable) makes sure it
 doesn't show up in the job logs. The variable cannot be
-[protected](../ci/variables/README.md#protect-a-cicd-variable), as it needs
+[protected](../ci/variables/index.md#protect-a-cicd-variable), as it needs
 to be present for all feature branches.

doc/development/gitaly.md

@@ -213,7 +213,7 @@ GITALY_REPO_URL=https://gitlab+deploy-token-1000:token-here@gitlab.com/nick.thom
 
 To use a custom Gitaly repository in CI/CD, for instance if you want your
 GitLab fork to always use your own Gitaly fork, set `GITALY_REPO_URL`
-as a [CI/CD variable](../ci/variables/README.md).
+as a [CI/CD variable](../ci/variables/index.md).
 
 ### Use a locally modified version of Gitaly RPC client
 

doc/development/integrations/secure.md

@@ -171,7 +171,7 @@ It also generates text output on the standard output and standard error streams,
 ### Variables
 
 All CI/CD variables are passed to the scanner as environment variables.
-The scanned project is described by the [predefined CI/CD variables](../../ci/variables/README.md).
+The scanned project is described by the [predefined CI/CD variables](../../ci/variables/index.md).
 
 #### SAST and Dependency Scanning
 

doc/install/aws/index.md

@@ -722,7 +722,7 @@ that you can ping and get reports.
 
 ## GitLab Runner
 
-If you want to take advantage of [GitLab CI/CD](../../ci/README.md), you have to
+If you want to take advantage of [GitLab CI/CD](../../ci/index.md), you have to
 set up at least one [runner](https://docs.gitlab.com/runner/).
 
 Read more on configuring an

doc/integration/jenkins.md

@@ -18,7 +18,7 @@ To better understand the GitLab Jenkins integration, watch the following video:
 
 Use the Jenkins integration with GitLab when:
 
-- You plan to migrate your CI from Jenkins to [GitLab CI/CD](../ci/README.md) in the future, but
+- You plan to migrate your CI from Jenkins to [GitLab CI/CD](../ci/index.md) in the future, but
 need an interim solution.
 - You're invested in [Jenkins Plugins](https://plugins.jenkins.io/) and choose to keep using Jenkins
 to build your apps.

doc/operations/metrics/dashboards/variables.md

@@ -16,7 +16,7 @@ Queries that continue to use the old format display no data.
 
 ## Predefined variables
 
-GitLab supports a limited set of [CI/CD variables](../../../ci/variables/README.md)
+GitLab supports a limited set of [CI/CD variables](../../../ci/variables/index.md)
 in the Prometheus query. This is particularly useful for identifying a specific
 environment, for example with `ci_environment_slug`. Variables for Prometheus queries
 must be lowercase. The supported variables are:

doc/raketasks/backup_restore.md

@@ -817,7 +817,7 @@ data into (`gitlabhq_production`). All existing data is either erased
 To restore a backup, you must restore `/etc/gitlab/gitlab-secrets.json`
 (for Omnibus packages) or `/home/git/gitlab/.secret` (for installations from
 source). This file contains the database encryption key,
-[CI/CD variables](../ci/variables/README.md), and
+[CI/CD variables](../ci/variables/index.md), and
 variables used for [two-factor authentication](../user/profile/account/two_factor_authentication.md).
 If you fail to restore this encryption key file along with the application data
 backup, users with two-factor authentication enabled and GitLab Runner
@@ -1188,7 +1188,7 @@ The secrets file is responsible for storing the encryption key for the columns
 that contain required, sensitive information. If the key is lost, GitLab can't
 decrypt those columns, preventing access to the following items:
 
-- [CI/CD variables](../ci/variables/README.md)
+- [CI/CD variables](../ci/variables/index.md)
 - [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)

doc/security/cicd_variables.md

 ---
-redirect_to: '../ci/variables/README.md#cicd-variable-security'
+redirect_to: '../ci/variables/index.md#cicd-variable-security'
 remove_date: '2021-07-04'
 ---
 
-This document was moved to [another location](../ci/variables/README.md#cicd-variable-security).
+This document was moved to [another location](../ci/variables/index.md#cicd-variable-security).
 
 <!-- This redirect file can be deleted after <2021-07-04>. -->
 <!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/security/index.md

@@ -23,7 +23,7 @@ type: index
 - [Send email confirmation on sign-up](user_email_confirmation.md)
 - [Security of running jobs](https://docs.gitlab.com/runner/security/)
 - [Proxying images](asset_proxy.md)
-- [CI/CD variables](../ci/variables/README.md#cicd-variable-security)
+- [CI/CD variables](../ci/variables/index.md#cicd-variable-security)
 - [Token overview](token_overview.md)
 - [Project Import decompressed archive size limits](project_import_decompressed_archive_size_limits.md)
 

doc/topics/autodevops/customize.md

@@ -146,7 +146,7 @@ repository or by specifying a project CI/CD variable:
   file in it, Auto DevOps detects the chart and uses it instead of the
   [default chart](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app), enabling
   you to control exactly how your application is deployed.
-- **Project variable** - Create a [project CI/CD variable](../../ci/variables/README.md)
+- **Project variable** - Create a [project CI/CD variable](../../ci/variables/index.md)
   `AUTO_DEVOPS_CHART` with the URL of a custom chart to use, or create two project
   variables: `AUTO_DEVOPS_CHART_REPOSITORY` with the URL of a custom chart repository,
   and `AUTO_DEVOPS_CHART` with the path to the chart.
@@ -181,7 +181,7 @@ list of options.
 ## Custom Helm chart per environment
 
 You can specify the use of a custom Helm chart per environment by scoping the CI/CD variable
-to the desired environment. See [Limit environment scope of CI/CD variables](../../ci/variables/README.md#limit-the-environment-scope-of-a-cicd-variable).
+to the desired environment. See [Limit environment scope of CI/CD variables](../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable).
 
 ## Customizing `.gitlab-ci.yml`
 
@@ -387,7 +387,7 @@ applications.
 
 NOTE:
 After you set up your replica variables using a
-[project CI/CD variable](../../ci/variables/README.md),
+[project CI/CD variable](../../ci/variables/index.md),
 you can scale your application by redeploying it.
 
 WARNING:
@@ -406,7 +406,7 @@ The following table lists CI/CD variables related to the database.
 | `POSTGRES_ENABLED`                      | Whether PostgreSQL is enabled. Defaults to `true`. Set to `false` to disable the automatic deployment of PostgreSQL. |
 | `POSTGRES_USER`                         | The PostgreSQL user. Defaults to `user`. Set it to use a custom username. |
 | `POSTGRES_PASSWORD`                     | The PostgreSQL password. Defaults to `testing-password`. Set it to use a custom password. |
-| `POSTGRES_DB`                           | The PostgreSQL database name. Defaults to the value of [`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.md#predefined-cicd-variables). Set it to use a custom database name. |
+| `POSTGRES_DB`                           | The PostgreSQL database name. Defaults to the value of [`$CI_ENVIRONMENT_SLUG`](../../ci/variables/index.md#predefined-cicd-variables). Set it to use a custom database name. |
 | `POSTGRES_VERSION`                      | Tag for the [`postgres` Docker image](https://hub.docker.com/_/postgres) to use. Defaults to `9.6.16` for tests and deployments as of GitLab 13.0 (previously `9.6.2`). If `AUTO_DEVOPS_POSTGRES_CHANNEL` is set to `1`, deployments uses the default version `9.6.2`. |
 
 ### Disable jobs

doc/topics/autodevops/index.md

@@ -232,7 +232,7 @@ any of the following places:
   **Settings > CI/CD** under the **Continuous Integration and Delivery** section.
 
 The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
-as other environment [variables](../../ci/variables/README.md#cicd-variable-precedence).
+as other environment [variables](../../ci/variables/index.md#cicd-variable-precedence).
 If the CI/CD variable is not set and the cluster setting is left blank, the instance-wide **Auto DevOps domain**
 setting is used if set.
 
@@ -275,7 +275,7 @@ used by Auto DevOps currently defines 3 environment names:
 Those environments are tied to jobs using [Auto Deploy](stages.md#auto-deploy), so
 except for the environment scope, they must have a different deployment domain.
 You must define a separate `KUBE_INGRESS_BASE_DOMAIN` variable for each of the above
-[based on the environment](../../ci/variables/README.md#limit-the-environment-scope-of-a-cicd-variable).
+[based on the environment](../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable).
 
 The following table is an example of how to configure the three different clusters:
 

doc/topics/build_your_application.md

@@ -11,6 +11,6 @@ code, and use CI/CD to generate your application. Include packages in your app a
 
 - [Repositories](../user/project/repository/index.md)
 - [Merge requests](../user/project/merge_requests/index.md)
-- [CI/CD](../ci/README.md)
+- [CI/CD](../ci/index.md)
 - [Packages & Registries](../user/packages/index.md)
 - [Application infrastructure](../user/project/clusters/index.md)

doc/topics/index.md

@@ -15,7 +15,7 @@ tutorials, technical overviews, blog posts) and videos.
 
 - [Auto DevOps](autodevops/index.md)
 - [Authentication](authentication/index.md)
-- [Continuous Integration (GitLab CI/CD)](../ci/README.md)
+- [Continuous Integration (GitLab CI/CD)](../ci/index.md)
 - [Cron](cron/index.md)
 - [Git](git/index.md)
 - [GitLab Flow](gitlab_flow.md)

doc/user/admin_area/settings/continuous_integration.md

@@ -195,8 +195,8 @@ As of June 22, 2020 the [value is set](../../gitlab_com/index.md#gitlab-cicd) to
 
 ## Protect CI/CD variables by default
 
-To set all new [CI/CD variables](../../../ci/variables/README.md) as
-[protected](../../../ci/variables/README.md#protect-a-cicd-variable) by default:
+To set all new [CI/CD variables](../../../ci/variables/index.md) as
+[protected](../../../ci/variables/index.md#protect-a-cicd-variable) by default:
 
 1. On the top bar, select **Menu >** **{admin}** **Admin**.
 1. On the left sidebar, select **Settings > CI/CD**.

doc/user/application_security/api_fuzzing/create_har_files.md

@@ -12,7 +12,7 @@ requests and HTTP responses. A HAR file's content is JSON formatted, containing
 with a web site. The file extension `.har` is commonly used.
 
 The HAR files can be used to perform [web API Fuzz Testing](index.md#http-archive-har) as part of
-your [GitLab CI/CD](../../../ci/README.md) pipelines.
+your [GitLab CI/CD](../../../ci/index.md) pipelines.
 
 WARNING:
 A HAR file stores information exchanged between web client and web server. It could also

doc/user/application_security/api_fuzzing/index.md

@@ -13,7 +13,7 @@ backend. This helps you discover bugs and potential security issues that other Q
 miss.
 
 We recommend that you use fuzz testing in addition to [GitLab Secure](../index.md)'s
-other security scanners and your own test processes. If you're using [GitLab CI/CD](../../../ci/README.md),
+other security scanners and your own test processes. If you're using [GitLab CI/CD](../../../ci/index.md),
 you can run fuzz tests as part your CI/CD workflow.
 
 ## When Web API fuzzing runs
@@ -400,7 +400,7 @@ To use HTTP basic authentication, two CI/CD variables are added to your `.gitlab
 - `FUZZAPI_HTTP_USERNAME`: The username for authentication.
 - `FUZZAPI_HTTP_PASSWORD`: The password for authentication.
 
-For the password, we recommended that you [create a CI/CD variable](../../../ci/variables/README.md#custom-cicd-variables)
+For the password, we recommended that you [create a CI/CD variable](../../../ci/variables/index.md#custom-cicd-variables)
 (for example, `TEST_API_PASSWORD`) set to the password. You can create CI/CD variables from the
 GitLab projects page at **Settings > CI/CD**, in the **Variables** section. Use that variable
 as the value for `FUZZAPI_HTTP_PASSWORD`:
@@ -438,7 +438,7 @@ outgoing HTTP requests.
 
 Follow these steps to provide the bearer token with `FUZZAPI_OVERRIDES_ENV`:
 
-1. [Create a CI/CD variable](../../../ci/variables/README.md#custom-cicd-variables),
+1. [Create a CI/CD variable](../../../ci/variables/index.md#custom-cicd-variables),
    for example `TEST_API_BEARERAUTH`, with the value
    `{"headers":{"Authorization":"Bearer dXNlcm5hbWU6cGFzc3dvcmQ="}}` (substitute your token). You
    can create CI/CD variables from the GitLab projects page at **Settings > CI/CD**, in the
@@ -780,7 +780,7 @@ variables:
 ```
 
 In this example `.gitlab-ci.yml`, the `SECRET_OVERRIDES` variable provides the JSON. This is a
-[group or instance level CI/CD variable defined in the UI](../../../ci/variables/README.md#add-a-cicd-variable-to-an-instance):
+[group or instance level CI/CD variable defined in the UI](../../../ci/variables/index.md#add-a-cicd-variable-to-an-instance):
 
 ```yaml
 stages:

doc/user/application_security/container_scanning/index.md

@@ -256,7 +256,7 @@ container_scanning:
         -----END CERTIFICATE-----
 ```
 
-The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a [custom variable in the UI](../../../ci/variables/README.md#custom-cicd-variables), either as a `file`, which requires the path to the certificate, or as a variable, which requires the text representation of the certificate.
+The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a [custom variable in the UI](../../../ci/variables/index.md#custom-cicd-variables), either as a `file`, which requires the path to the certificate, or as a variable, which requires the text representation of the certificate.
 
 ### Vulnerability allowlisting
 

doc/user/application_security/coverage_fuzzing/index.md

@@ -13,7 +13,7 @@ random inputs to an instrumented version of your application in an effort to cau
 behavior, such as a crash. Such behavior indicates a bug that you should address.
 
 We recommend that you use fuzz testing in addition to the other security scanners in [GitLab Secure](../index.md)
-and your own test processes. If you're using [GitLab CI/CD](../../../ci/README.md),
+and your own test processes. If you're using [GitLab CI/CD](../../../ci/index.md),
 you can run your coverage-guided fuzz tests as part your CI/CD workflow. You can take advantage of
 coverage-guided fuzzing by including the CI job in your existing `.gitlab-ci.yml` file.
 

doc/user/application_security/dast/index.md

@@ -550,7 +550,7 @@ you periodically confirm the scanner's authentication is still working, as this
 time due to authentication changes to the application.
 
 Create masked CI/CD variables to pass the credentials that DAST uses.
-To create masked variables for the username and password, see [Create a custom variable in the UI](../../../ci/variables/README.md#custom-cicd-variables).
+To create masked variables for the username and password, see [Create a custom variable in the UI](../../../ci/variables/index.md#custom-cicd-variables).
 The key of the username variable must be `DAST_USERNAME`,
 and the key of the password variable must be `DAST_PASSWORD`.
 

doc/user/application_security/dast_api/index.md

@@ -7,11 +7,11 @@ type: reference, howto
 
 # DAST API **(ULTIMATE)**
 
-You can add dynamic application security testing of web APIs to your [GitLab CI/CD](../../../ci/README.md) pipelines.
+You can add dynamic application security testing of web APIs to your [GitLab CI/CD](../../../ci/index.md) pipelines.
 This helps you discover bugs and potential security issues that other QA processes may miss.
 
 We recommend that you use DAST API testing in addition to [GitLab Secure](../index.md)'s
-other security scanners and your own test processes. If you're using [GitLab CI/CD](../../../ci/README.md),
+other security scanners and your own test processes. If you're using [GitLab CI/CD](../../../ci/index.md),
 you can run DAST API tests as part your CI/CD workflow.
 
 ## Requirements
@@ -435,7 +435,7 @@ To use HTTP basic authentication, two CI/CD variables are added to your `.gitlab
 - `DAST_API_HTTP_USERNAME`: The username for authentication.
 - `DAST_API_HTTP_PASSWORD`: The password for authentication.
 
-For the password, we recommended that you [create a CI/CD variable](../../../ci/variables/README.md#custom-cicd-variables)
+For the password, we recommended that you [create a CI/CD variable](../../../ci/variables/index.md#custom-cicd-variables)
 (for example, `TEST_API_PASSWORD`) set to the password. You can create CI/CD variables from the
 GitLab projects page at **Settings > CI/CD**, in the **Variables** section. Use that variable
 as the value for `DAST_API_HTTP_PASSWORD`:
@@ -473,7 +473,7 @@ outgoing HTTP requests.
 
 Follow these steps to provide the bearer token with `DAST_API_OVERRIDES_ENV`:
 
-1. [Create a CI/CD variable](../../../ci/variables/README.md#custom-cicd-variables),
+1. [Create a CI/CD variable](../../../ci/variables/index.md#custom-cicd-variables),
    for example `TEST_API_BEARERAUTH`, with the value
    `{"headers":{"Authorization":"Bearer dXNlcm5hbWU6cGFzc3dvcmQ="}}` (substitute your token). You
    can create CI/CD variables from the GitLab projects page at **Settings > CI/CD**, in the
@@ -849,7 +849,7 @@ variables:
 ```
 
 In this example `.gitlab-ci.yml`, the `SECRET_OVERRIDES` variable provides the JSON. This is a
-[group or instance level CI/CD variable defined in the UI](../../../ci/variables/README.md#add-a-cicd-variable-to-an-instance):
+[group or instance level CI/CD variable defined in the UI](../../../ci/variables/index.md#add-a-cicd-variable-to-an-instance):
 
 ```yaml
 stages:

doc/user/application_security/dependency_scanning/index.md

@@ -16,7 +16,7 @@ vulnerable. You can then take action to protect your application.
 
 ## Overview
 
-If you're using [GitLab CI/CD](../../../ci/README.md), you can use dependency scanning to analyze
+If you're using [GitLab CI/CD](../../../ci/index.md), you can use dependency scanning to analyze
 your dependencies for known vulnerabilities. GitLab scans all dependencies, including transitive
 dependencies (also known as nested dependencies). You can take advantage of dependency scanning by
 either:
@@ -217,7 +217,7 @@ variables:
       -----END CERTIFICATE-----
 ```
 
-The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a [custom variable in the UI](../../../ci/variables/README.md#custom-cicd-variables), either as a `file`, which requires the path to the certificate, or as a variable, which requires the text representation of the certificate.
+The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a [custom variable in the UI](../../../ci/variables/index.md#custom-cicd-variables), either as a `file`, which requires the path to the certificate, or as a variable, which requires the text representation of the certificate.
 
 ### Using private Maven repositories
 

doc/user/application_security/index.md

@@ -237,7 +237,7 @@ to pass a username and password. You can set it under your project's settings
 so that your credentials aren't exposed in `.gitlab-ci.yml`.
 
 If the username is `myuser` and the password is `verysecret` then you would
-[set the following variable](../../ci/variables/README.md#custom-cicd-variables)
+[set the following variable](../../ci/variables/index.md#custom-cicd-variables)
 under your project's settings:
 
 | Type     | Key              | Value |
@@ -405,7 +405,7 @@ This is often followed by the [error `No files to upload`](../../ci/pipelines/jo
 and preceded by other errors or warnings that indicate why the JSON report wasn't generated. Please
 check the entire job log for such messages. If you don't find these messages, retry the failed job
 after setting `SECURE_LOG_LEVEL: "debug"` as a
-[custom CI/CD variable](../../ci/variables/README.md#custom-cicd-variables).
+[custom CI/CD variable](../../ci/variables/index.md#custom-cicd-variables).
 This provides useful information to investigate further.
 
 ### Getting error message `sast job: config key may not be used with 'rules': only/except`

doc/user/application_security/offline_deployments/index.md

@@ -149,7 +149,7 @@ GitLab.com. To do so, set the CI/CD variable `SECURE_ANALYZERS_PREFIX` with the
 project [container registry](../../packages/container_registry/index.md).
 
 You can set this variable in the projects' `.gitlab-ci.yml`, or
-in the GitLab UI at the project or group level. See the [GitLab CI/CD variables page](../../../ci/variables/README.md#custom-cicd-variables)
+in the GitLab UI at the project or group level. See the [GitLab CI/CD variables page](../../../ci/variables/index.md#custom-cicd-variables)
 for more information.
 
 #### Variables

doc/user/application_security/sast/index.md

@@ -15,7 +15,7 @@ The whitepaper ["A Seismic Shift in Application Security"](https://about.gitlab.
 explains how 4 of the top 6 attacks were application based. Download it to learn how to protect your
 organization.
 
-If you're using [GitLab CI/CD](../../../ci/README.md), you can use Static Application Security
+If you're using [GitLab CI/CD](../../../ci/index.md), you can use Static Application Security
 Testing (SAST) to check your source code for known vulnerabilities. When a pipeline completes,
 the results of the SAST analysis are processed and shown in the pipeline's Security tab. If the
 pipeline is associated with a merge request, the SAST analysis is compared with the results of
@@ -465,7 +465,7 @@ variables:
       -----END CERTIFICATE-----
 ```
 
-The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a [custom variable in the UI](../../../ci/variables/README.md#custom-cicd-variables), either as a `file`, which requires the path to the certificate, or as a variable, which requires the text representation of the certificate.
+The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a [custom variable in the UI](../../../ci/variables/index.md#custom-cicd-variables), either as a `file`, which requires the path to the certificate, or as a variable, which requires the text representation of the certificate.
 
 #### Docker images
 
@@ -521,7 +521,7 @@ Some analyzers can be customized with CI/CD variables.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18193) in GitLab Ultimate 12.5.
 
 In addition to the aforementioned SAST configuration CI/CD variables,
-all [custom variables](../../../ci/variables/README.md#custom-cicd-variables) are propagated
+all [custom variables](../../../ci/variables/index.md#custom-cicd-variables) are propagated
 to the underlying SAST analyzer images if
 [the SAST vendored template](#configuration) is used.
 

doc/user/clusters/applications.md

@@ -393,14 +393,14 @@ For GitLab Runner to function, you _must_ specify the following:
 - `runnerRegistrationToken`: The registration token for adding new runners to GitLab.
   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):
+These values can be specified using [CI/CD variables](../../ci/variables/index.md):
 
 - `GITLAB_RUNNER_GITLAB_URL` is used for `gitlabUrl`.
 - `GITLAB_RUNNER_REGISTRATION_TOKEN` is used for `runnerRegistrationToken`
 
 The methods of specifying these values are mutually exclusive. Either specify variables `GITLAB_RUNNER_REGISTRATION_TOKEN` and `GITLAB_RUNNER_TOKEN` as CI variables (recommended) or provide values for `runnerRegistrationToken:` and `runnerToken:` in `.gitlab/managed-apps/gitlab-runner/values.yaml`. If you choose to use CI variables, comment out or remove `runnerRegistrationToken:` and `runnerToken:` from `.gitlab/managed-apps/gitlab-runner/values`.
 
-The runner registration token allows connection to a project by a runner and therefore should be treated as a secret to prevent malicious use and code exfiltration through a runner. For this reason, we recommend that you specify the runner registration token as a [protected variable](../../ci/variables/README.md#protect-a-cicd-variable) and [masked variable](../../ci/variables/README.md#mask-a-cicd-variable) and do not commit them to the Git repository in the `values.yaml` file.
+The runner registration token allows connection to a project by a runner and therefore should be treated as a secret to prevent malicious use and code exfiltration through a runner. For this reason, we recommend that you specify the runner registration token as a [protected variable](../../ci/variables/index.md#protect-a-cicd-variable) and [masked variable](../../ci/variables/index.md#mask-a-cicd-variable) and do not commit them to the Git repository in the `values.yaml` file.
 
 You can customize the installation of GitLab Runner by defining
 `.gitlab/managed-apps/gitlab-runner/values.yaml` file in your cluster
@@ -762,7 +762,7 @@ Set:
 - "Redirect URI" to `http://<JupyterHub Host>/hub/oauth_callback`.
 - "Scope" to `api read_repository write_repository`.
 
-In addition, the following variables must be specified using [CI/CD variables](../../ci/variables/README.md):
+In addition, the following variables must be specified using [CI/CD variables](../../ci/variables/index.md):
 
 - `JUPYTERHUB_PROXY_SECRET_TOKEN` - Secure string used for signing communications
   from the hub. Read [`proxy.secretToken`](https://zero-to-jupyterhub.readthedocs.io/en/stable/reference/reference.html#proxy-secrettoken).

doc/user/compliance/license_compliance/index.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5483) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.0.
 
-If you're using [GitLab CI/CD](../../../ci/README.md), you can use License Compliance to search your
+If you're using [GitLab CI/CD](../../../ci/index.md), you can use License Compliance to search your
 project's dependencies for their licenses. You can then decide whether to allow or deny the use of
 each license. For example, if your application uses an external (open source) library whose license
 is incompatible with yours, then you can deny the use of that license.
@@ -370,7 +370,7 @@ source "https://gems.example.com"
 You can supply a custom root certificate to complete TLS verification by using the
 `ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-cicd-variables), or by
 specifying a [`BUNDLE_SSL_CA_CERT`](https://bundler.io/v2.0/man/bundle-config.1.html)
-[variable](../../../ci/variables/README.md#custom-cicd-variables)
+[variable](../../../ci/variables/index.md#custom-cicd-variables)
 in the job definition.
 
 ### Configuring Cargo projects
@@ -394,7 +394,7 @@ To supply a custom root certificate to complete TLS verification, do one of the
 
 - Use the `ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-cicd-variables).
 - Specify a [`CARGO_HTTP_CAINFO`](https://doc.rust-lang.org/cargo/reference/environment-variables.html)
-  [variable](../../../ci/variables/README.md#custom-cicd-variables)
+  [variable](../../../ci/variables/index.md#custom-cicd-variables)
   in the job definition.
 
 ### Configuring Composer projects
@@ -427,7 +427,7 @@ For example:
 You can supply a custom root certificate to complete TLS verification by using the
 `ADDITIONAL_CA_CERT_BUNDLE` [CI/CD variable](#available-cicd-variables), or by
 specifying a [`COMPOSER_CAFILE`](https://getcomposer.org/doc/03-cli.md#composer-cafile)
-[variable](../../../ci/variables/README.md#custom-cicd-variables)
+[variable](../../../ci/variables/index.md#custom-cicd-variables)
 in the job definition.
 
 ### Configuring Conan projects
@@ -490,7 +490,7 @@ example:
 }
 ```
 
-If credentials are required to authenticate then you can configure a [protected CI/CD variable](../../../ci/variables/README.md#protect-a-cicd-variable)
+If credentials are required to authenticate then you can configure a [protected CI/CD variable](../../../ci/variables/index.md#protect-a-cicd-variable)
 following the naming convention described in the [`CONAN_LOGIN_USERNAME` documentation](https://docs.conan.io/en/latest/reference/env_vars.html#conan-login-username-conan-login-username-remote-name).
 
 #### Custom root certificates for Conan

doc/user/gitlab_com/index.md

@@ -104,7 +104,7 @@ which is part of [GitLab CI/CD](#gitlab-cicd).
 
 ## GitLab CI/CD
 
-Below are the current settings regarding [GitLab CI/CD](../../ci/README.md).
+Below are the current settings regarding [GitLab CI/CD](../../ci/index.md).
 Any settings or feature limits not listed here are using the defaults listed in
 the related documentation.
 

doc/user/group/clusters/index.md

@@ -103,7 +103,7 @@ The domain should have a wildcard DNS configured to the Ingress IP address. [Mor
 When adding more than one Kubernetes cluster to your project, you need to differentiate
 them with an environment scope. The environment scope associates clusters with
 [environments](../../../ci/environments/index.md) similar to how the
-[environment-specific CI/CD variables](../../../ci/variables/README.md#limit-the-environment-scope-of-a-cicd-variable)
+[environment-specific CI/CD variables](../../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable)
 work.
 
 While evaluating which environment matches the environment scope of a

doc/user/index.md

@@ -46,7 +46,7 @@ GitLab is a Git-based platform that integrates a great number of essential tools
 - Organizing and prioritizing with [Issue Boards](project/issue_board.md).
 - Reviewing code in [Merge Requests](project/merge_requests/index.md) with live-preview changes per
   branch with [Review Apps](../ci/review_apps/index.md).
-- Building, testing, and deploying with built-in [Continuous Integration](../ci/README.md).
+- Building, testing, and deploying with built-in [Continuous Integration](../ci/index.md).
 - Deploying personal and professional static websites with [GitLab Pages](project/pages/index.md).
 - Integrating with Docker by using [GitLab Container Registry](packages/container_registry/index.md).
 - Tracking the development lifecycle by using [GitLab Value Stream Analytics](analytics/value_stream_analytics.md).
@@ -164,7 +164,7 @@ you have quick access to. You can also gather feedback on them through
 
 ## GitLab CI/CD
 
-Use built-in [GitLab CI/CD](../ci/README.md) to test, build, and deploy your applications
+Use built-in [GitLab CI/CD](../ci/index.md) to test, build, and deploy your applications
 directly from GitLab. No third-party integrations needed.
 
 ## Features behind feature flags

doc/user/packages/composer_repository/index.md

@@ -293,7 +293,7 @@ To install a package:
 WARNING:
 Never commit the `auth.json` file to your repository. To install packages from a CI/CD job,
 consider using the [`composer config`](https://getcomposer.org/doc/articles/handling-private-packages.md#satis) tool with your personal access token
-stored in a [GitLab CI/CD variable](../../../ci/variables/README.md) or in
+stored in a [GitLab CI/CD variable](../../../ci/variables/index.md) or in
 [HashiCorp Vault](../../../ci/secrets/index.md).
 
 ## Supported CLI commands

doc/user/packages/conan_repository/index.md

@@ -269,7 +269,7 @@ conan upload Hello/0.1@mycompany/beta --all
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/11678) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.7.
 
-To work with Conan commands in [GitLab CI/CD](../../../ci/README.md), you can
+To work with Conan commands in [GitLab CI/CD](../../../ci/index.md), you can
 use `CI_JOB_TOKEN` in place of the personal access token in your commands.
 
 You can provide the `CONAN_LOGIN_USERNAME` and `CONAN_PASSWORD` with each Conan

doc/user/packages/container_registry/index.md

@@ -210,7 +210,7 @@ build:
     - docker push $CI_REGISTRY/group/project/image:latest
 ```
 
-You can also make use of [other CI/CD variables](../../../ci/variables/README.md) to avoid hard-coding:
+You can also make use of [other CI/CD variables](../../../ci/variables/index.md) to avoid hard-coding:
 
 ```yaml
 build:

doc/user/packages/dependency_proxy/index.md

@@ -123,7 +123,7 @@ Proxy manually without including the port:
 docker pull gitlab.example.com:443/my-group/dependency_proxy/containers/alpine:latest
 ```
 
-You can also use [custom CI/CD variables](../../../ci/variables/README.md#custom-cicd-variables) to store and access your personal access token or other valid credentials.
+You can also use [custom CI/CD variables](../../../ci/variables/index.md#custom-cicd-variables) to store and access your personal access token or other valid credentials.
 
 ### Store a Docker image in Dependency Proxy cache
 
@@ -180,7 +180,7 @@ Watch how to [use the Dependency Proxy to help avoid Docker Hub rate limits](htt
 
 In November 2020, Docker introduced
 [rate limits on pull requests from Docker Hub](https://docs.docker.com/docker-hub/download-rate-limit/).
-If your GitLab [CI/CD configuration](../../../ci/README.md) uses
+If your GitLab [CI/CD configuration](../../../ci/index.md) uses
 an image from Docker Hub, each time a job runs, it may count as a pull request.
 To help get around this limit, you can pull your image from the Dependency Proxy cache instead.
 

doc/user/packages/generic_packages/index.md

@@ -108,7 +108,7 @@ curl --user "user:<your_access_token>" \
 
 ## Publish a generic package by using CI/CD
 
-To work with generic packages in [GitLab CI/CD](../../../ci/README.md), you can use
+To work with generic packages in [GitLab CI/CD](../../../ci/index.md), you can use
 `CI_JOB_TOKEN` in place of the personal access token in your commands.
 
 For example:

doc/user/packages/infrastructure_registry/index.md

@@ -35,7 +35,7 @@ documentation for your package type:
 
 ## Use GitLab CI/CD to build packages
 
-To use [GitLab CI/CD](../../../ci/README.md) to build packages, you can
+To use [GitLab CI/CD](../../../ci/index.md) to build packages, you can
 authenticate with the [`CI_JOB_TOKEN` predefined variable](../../../ci/variables/predefined_variables.md).
 
 CI/CD templates, which you can use to get started, are in [this repository](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates).

doc/user/packages/npm_registry/index.md

@@ -205,7 +205,7 @@ Then, you can run `npm publish` either locally or by using GitLab CI/CD.
   NPM_TOKEN=<your_token> npm publish
   ```
 
-- **GitLab CI/CD:** Set an `NPM_TOKEN` [CI/CD variable](../../../ci/variables/README.md)
+- **GitLab CI/CD:** Set an `NPM_TOKEN` [CI/CD variable](../../../ci/variables/index.md)
   under your project's **Settings > CI/CD > Variables**.
 
 ## Package naming convention
@@ -287,7 +287,7 @@ Prerequisites:
   It must match exactly, including the case. This is different than the
   npm naming convention, but it is required to work with the GitLab Package Registry.
 
-To work with npm commands within [GitLab CI/CD](../../../ci/README.md), you can use
+To work with npm commands within [GitLab CI/CD](../../../ci/index.md), you can use
 `CI_JOB_TOKEN` in place of the personal access token or deploy token in your commands.
 
 An example `.gitlab-ci.yml` file for publishing npm packages:
@@ -512,7 +512,7 @@ And the `.npmrc` file should look like:
 
 ### `npm install` returns `Error: Failed to replace env in config: ${npm_TOKEN}`
 
-You do not need a token to run `npm install` unless your project is private. The token is only required to publish. If the `.npmrc` file was checked in with a reference to `$npm_TOKEN`, you can remove it. If you prefer to leave the reference in, you must set a value prior to running `npm install` or set the value by using [GitLab CI/CD variables](../../../ci/variables/README.md):
+You do not need a token to run `npm install` unless your project is private. The token is only required to publish. If the `.npmrc` file was checked in with a reference to `$npm_TOKEN`, you can remove it. If you prefer to leave the reference in, you must set a value prior to running `npm install` or set the value by using [GitLab CI/CD variables](../../../ci/variables/index.md):
 
 ```shell
 NPM_TOKEN=<your_token> npm install

doc/user/packages/package_registry/index.md

@@ -34,7 +34,7 @@ For information on how to create and upload a package, view the GitLab documenta
 
 ## Use GitLab CI/CD to build packages
 
-You can use [GitLab CI/CD](../../../ci/README.md) to build packages.
+You can use [GitLab CI/CD](../../../ci/index.md) to build packages.
 For Maven, NuGet, npm, Conan, and PyPI packages, and Composer dependencies, you can
 authenticate with GitLab by using the `CI_JOB_TOKEN`.
 

doc/user/packages/pypi_repository/index.md

@@ -204,7 +204,7 @@ Your project ID is on your project's home page.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202012) in GitLab 13.4.
 
-To work with PyPI commands within [GitLab CI/CD](../../../ci/README.md), you
+To work with PyPI commands within [GitLab CI/CD](../../../ci/index.md), you
 can use `CI_JOB_TOKEN` instead of a personal access token or deploy token.
 
 For example:

doc/user/packages/rubygems_registry/index.md

@@ -74,7 +74,7 @@ https://gitlab.example.com/api/v4/projects/<project_id>/packages/rubygems: '<you
 
 ### Authenticate with a CI job token
 
-To work with RubyGems commands within [GitLab CI/CD](../../../ci/README.md),
+To work with RubyGems commands within [GitLab CI/CD](../../../ci/index.md),
 you can use `CI_JOB_TOKEN` instead of a personal access token or deploy token.
 
 For example:

doc/user/packages/terraform_module_registry/index.md

@@ -99,7 +99,7 @@ module "<module>" {
 
 ## Publish a Terraform module by using CI/CD
 
-To work with Terraform modules in [GitLab CI/CD](../../../ci/README.md), you can use
+To work with Terraform modules in [GitLab CI/CD](../../../ci/index.md), you can use
 `CI_JOB_TOKEN` in place of the personal access token in your commands.
 
 For example:

doc/user/permissions.md

@@ -59,7 +59,7 @@ The following table lists project permissions available for each role:
 | View wiki pages                                   | ✓       | ✓          | ✓           | ✓        | ✓      |
 | See a list of jobs                                | ✓ (*3*) | ✓          | ✓           | ✓        | ✓      |
 | See a job log                                     | ✓ (*3*) | ✓          | ✓           | ✓        | ✓      |
-| See a job with [debug logging](../ci/variables/README.md#debug-logging) |         |            | ✓           | ✓        | ✓      |
+| See a job with [debug logging](../ci/variables/index.md#debug-logging) |         |            | ✓           | ✓        | ✓      |
 | Download and browse job artifacts                 | ✓ (*3*) | ✓          | ✓           | ✓        | ✓      |
 | Create confidential issue                         | ✓       | ✓          | ✓           | ✓        | ✓      |
 | Create new issue                                  | ✓       | ✓          | ✓           | ✓        | ✓      |

doc/user/project/clusters/deploy_to_cluster.md

@@ -14,7 +14,7 @@ A Kubernetes cluster can be the destination for a deployment job. If
   the cluster from your jobs using tools such as `kubectl` or `helm`.
 - You don't use the GitLab cluster integration, you can still deploy to your
   cluster. However, you must configure Kubernetes tools yourself
-  using [CI/CD variables](../../../ci/variables/README.md#custom-cicd-variables)
+  using [CI/CD variables](../../../ci/variables/index.md#custom-cicd-variables)
   before you can interact with the cluster from your jobs.
 
 ## Deployment variables
@@ -36,7 +36,7 @@ following command in your deployment job script, for Kubernetes to access the re
   ```
 
 The Kubernetes cluster integration exposes these
-[deployment variables](../../../ci/variables/README.md#deployment-variables) in the
+[deployment variables](../../../ci/variables/index.md#deployment-variables) in the
 GitLab CI/CD build environment to deployment jobs. Deployment jobs have
 [defined a target environment](../../../ci/environments/index.md).
 

doc/user/project/clusters/multiple_kubernetes_clusters.md

@@ -20,7 +20,7 @@ differentiates the new cluster from the rest.
 
 When adding more than one Kubernetes cluster to your project, you need to differentiate
 them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments/index.md) similar to how the
-[environment-specific CI/CD variables](../../../ci/variables/README.md#limit-the-environment-scope-of-a-cicd-variable) work.
+[environment-specific CI/CD variables](../../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable) work.
 
 The default environment scope is `*`, which means all jobs, regardless of their
 environment, use that cluster. Each scope can be used only by a single cluster

doc/user/project/clusters/serverless/aws.md

@@ -134,7 +134,7 @@ This example code does the following:
 #### Setting up your AWS credentials with your GitLab account
 
 In order to interact with your AWS account, the GitLab CI/CD pipelines require both `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be defined in your GitLab settings under **Settings > CI/CD > Variables**.
-For more information please see [Create a custom variable in the UI](../../../../ci/variables/README.md#custom-variables-validated-by-gitlab).
+For more information please see [Create a custom variable in the UI](../../../../ci/variables/index.md#custom-variables-validated-by-gitlab).
 
  The AWS credentials you provide must include IAM policies that provision correct
  access control to AWS Lambda, API Gateway, CloudFormation, and IAM resources.

doc/user/project/clusters/serverless/index.md

@@ -364,7 +364,7 @@ kubectl create secret generic my-secrets -n "$KUBE_NAMESPACE" --from-literal MY_
 
 #### Part of deployment job
 
-You can extend your `.gitlab-ci.yml` to create the secrets during deployment using the [CI/CD variables](../../../../ci/variables/README.md)
+You can extend your `.gitlab-ci.yml` to create the secrets during deployment using the [CI/CD variables](../../../../ci/variables/index.md)
 stored securely under your GitLab project.
 
 ```yaml

doc/user/project/deploy_boards.md

@@ -165,6 +165,6 @@ version of your application.
 ## Further reading
 
 - [GitLab Auto deploy](../../topics/autodevops/stages.md#auto-deploy)
-- [GitLab CI/CD variables](../../ci/variables/README.md)
+- [GitLab CI/CD variables](../../ci/variables/index.md)
 - [Environments and deployments](../../ci/environments/index.md)
 - [Kubernetes deploy example](https://gitlab.com/gitlab-examples/kubernetes-deploy)

doc/user/project/index.md

@@ -65,7 +65,7 @@ Projects include the following [features](https://about.gitlab.com/features/):
 
 **GitLab CI/CD:**
 
-- [GitLab CI/CD](../../ci/README.md): Use the built-in [Continuous Integration, Delivery, and Deployment](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) tool.
+- [GitLab CI/CD](../../ci/index.md): Use the built-in [Continuous Integration, Delivery, and Deployment](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) tool.
   - [Container Registry](../packages/container_registry/index.md): Build and push Docker
   images.
   - [Auto Deploy](../../topics/autodevops/stages.md#auto-deploy): Configure GitLab CI/CD

doc/user/project/integrations/prometheus_library/index.md

@@ -35,6 +35,6 @@ In order to isolate and only display relevant metrics for a given environment,
 GitLab needs a method to detect which labels are associated. To do that,
 GitLab uses the defined queries and fills in the environment specific variables.
 Typically this involves looking for the
-[`$CI_ENVIRONMENT_SLUG`](../../../../ci/variables/README.md#predefined-cicd-variables),
+[`$CI_ENVIRONMENT_SLUG`](../../../../ci/variables/index.md#predefined-cicd-variables),
 but may also include other information such as the project's Kubernetes namespace.
 Each search query is defined in the [exporter specific documentation](#exporters).

doc/user/project/integrations/prometheus_library/kubernetes.md

@@ -40,7 +40,7 @@ Prometheus needs to be deployed into the cluster and configured properly in orde
 
 In order to isolate and only display relevant CPU and Memory metrics for a given environment, GitLab needs a method to detect which containers it is running. Because these metrics are tracked at the container level, traditional Kubernetes labels are not available.
 
-Instead, the [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) or [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) name should begin with [CI_ENVIRONMENT_SLUG](../../../../ci/variables/README.md#predefined-cicd-variables). It can be followed by a `-` and additional content if desired. For example, a deployment name of `review-homepage-5620p5` would match the `review/homepage` environment.
+Instead, the [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) or [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) name should begin with [CI_ENVIRONMENT_SLUG](../../../../ci/variables/index.md#predefined-cicd-variables). It can be followed by a `-` and additional content if desired. For example, a deployment name of `review-homepage-5620p5` would match the `review/homepage` environment.
 
 ## Displaying Canary metrics **(PREMIUM)**
 

doc/user/project/merge_requests/accessibility_testing.md

@@ -10,7 +10,7 @@ type: reference, howto
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25144) in GitLab 12.8.
 
 If your application offers a web interface and you are using
-[GitLab CI/CD](../../../ci/README.md), you can quickly determine the accessibility
+[GitLab CI/CD](../../../ci/index.md), you can quickly determine the accessibility
 impact of pending code changes.
 
 ## Overview

doc/user/project/merge_requests/browser_performance_testing.md

@@ -10,7 +10,7 @@ type: reference, howto
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3507) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.3.
 
 If your application offers a web interface and you're using
-[GitLab CI/CD](../../../ci/README.md), you can quickly determine the rendering performance
+[GitLab CI/CD](../../../ci/index.md), you can quickly determine the rendering performance
 impact of pending code changes in the browser.
 
 NOTE:

doc/user/project/merge_requests/code_quality.md

@@ -10,7 +10,7 @@ type: reference, howto
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1984) in GitLab 9.3.
 > - Made [available in all tiers](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) in 13.2.
 
-Ensuring your project's code stays simple, readable and easy to contribute to can be problematic. With the help of [GitLab CI/CD](../../../ci/README.md), you can analyze your
+Ensuring your project's code stays simple, readable and easy to contribute to can be problematic. With the help of [GitLab CI/CD](../../../ci/index.md), you can analyze your
 source code quality using GitLab Code Quality.
 
 Code Quality:
@@ -262,13 +262,13 @@ was chosen as an operational decision by the runner team, instead of exposing `d
 ### Disabling the code quality job
 
 The `code_quality` job doesn't run if the `$CODE_QUALITY_DISABLED` CI/CD variable
-is present. Please refer to the CI/CD variables [documentation](../../../ci/variables/README.md)
+is present. Please refer to the CI/CD variables [documentation](../../../ci/variables/index.md)
 to learn more about how to define one.
 
 To disable the `code_quality` job, add `CODE_QUALITY_DISABLED` as a custom CI/CD variable.
 This can be done:
 
-- For [the whole project](../../../ci/variables/README.md#custom-cicd-variables).
+- For [the whole project](../../../ci/variables/index.md#custom-cicd-variables).
 - For a single pipeline run:
 
   1. Go to **CI/CD > Pipelines**

doc/user/project/merge_requests/index.md

@@ -33,7 +33,7 @@ important parts of the merge request:
   [merge request widgets area](widgets.md) reports results from pipelines and tests.
 - **Commits**: Contains a list of commits added to this merge request. For more
   information, read [Commits tab in merge requests](commits.md).
-- **Pipelines**: If configured, contains a list of recent [GitLab CI/CD](../../../ci/README.md)
+- **Pipelines**: If configured, contains a list of recent [GitLab CI/CD](../../../ci/index.md)
   pipelines and their status.
 - **Changes**: Contains the diffs of files changed by this merge request. You can
   [configure the display](changes.md).

doc/user/project/merge_requests/load_performance_testing.md

@@ -10,7 +10,7 @@ type: reference, howto
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10683) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.2.
 
 With Load Performance Testing, you can test the impact of any pending code changes
-to your application's backend in [GitLab CI/CD](../../../ci/README.md).
+to your application's backend in [GitLab CI/CD](../../../ci/index.md).
 
 GitLab uses [k6](https://k6.io/), a free and open source
 tool, for measuring the system performance of applications under

doc/user/project/merge_requests/test_coverage_visualization.md

@@ -10,7 +10,7 @@ type: reference, howto
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3708) in GitLab 12.9.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/249811) in GitLab 13.5.
 
-With the help of [GitLab CI/CD](../../../ci/README.md), you can collect the test
+With the help of [GitLab CI/CD](../../../ci/index.md), you can collect the test
 coverage information of your favorite testing or coverage-analysis tool, and visualize
 this information inside the file diff view of your merge requests (MRs). This will allow you
 to see which lines are covered by tests, and which lines still require coverage, before the