Update variable naming to stop busing environment

Name them CI/CD variables, not environment variables,
for clarity and consistency. It avoids them being confused
with the environments feature, or build/job environments.

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: 'instance-level-cicd-environment-variables'), target: '_blank', rel: 'noopener noreferrer'
+  = link_to s_('Learn more.'), help_page_path('ci/variables/README', anchor: 'instance-level-cicd-variables'), target: '_blank', rel: 'noopener noreferrer'
 %p
   = _('Variables can be:')
 %ul

doc/ci/caching/index.md

@@ -87,7 +87,7 @@ use one or more of the following:
   that are only available to a particular project.
 - [Use a `key`](../yaml/README.md#cachekey) that fits your workflow (for example,
   different caches on each branch). For that, you can take advantage of the
-  [CI/CD predefined variables](../variables/README.md#predefined-environment-variables).
+  [predefined CI/CD variables](../variables/README.md#predefined-cicd-variables).
 
 For runners to work with caches efficiently, you must do one of the following:
 

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-environment-variables)
+ChatOps passes the following [CI/CD variables](../variables/README.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-environment-variables) like
+  [CI/CD variables](../variables/README.md#predefined-cicd-variables) like
   `GITLAB_USER_ID` to perform additional rights validation, but
-  these variables can be [overridden](../variables/README.md#priority-of-environment-variables).
+  these variables can be [overridden](../variables/README.md#priority-of-cicd-variables).
 
 ### Controlling the ChatOps reply
 

doc/ci/cloud_deployment/index.md

@@ -38,7 +38,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
-   [environment variables](../variables/README.md#gitlab-cicd-environment-variables)
+   [CI/CD variables](../variables/README.md)
    (see table below):
 
    - Access key ID.
@@ -141,15 +141,15 @@ After you have these prerequisites ready, follow these steps:
    ```
 
    You can create your `CI_AWS_ECS_TASK_DEFINITION_FILE` variable as a
-   [file-typed environment variable](../variables/README.md#custom-environment-variables-of-type-file) instead of a
-   regular environment variable. If you choose to do so, set the variable value to be the full contents of
+   [file-typed CI/CD variable](../variables/README.md#custom-cicd-variables-of-type-file) 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.
 
    In both cases, make sure that the value for the `containerDefinitions[].name` attribute is
    the same as the `Container name` defined in your targeted ECS service.
 
    WARNING:
-   `CI_AWS_ECS_TASK_DEFINITION_FILE` takes precedence over `CI_AWS_ECS_TASK_DEFINITION` if both these environment
+   `CI_AWS_ECS_TASK_DEFINITION_FILE` takes precedence over `CI_AWS_ECS_TASK_DEFINITION` if both these
    variables are defined within your project.
 
    NOTE:
@@ -252,12 +252,12 @@ 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 environment variables](../variables/README.md#custom-environment-variables-of-type-file).
-   In your project, go to **Settings > CI / CD > Variables** and add
-   the three variables listed above as file-typed environment variables.
-   For each variable, set the value to its corresponding JSON object.
+   - Alternatively, you can provide these JSON objects as [file-typed CI/CD variables](../variables/README.md#custom-cicd-variables-of-type-file).
+     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.
 
-1. Provide the name of the stack you're creating and/or targeting, as an environment variable:
+1. Provide the name of the stack you're creating and/or targeting, as a CI/CD variable:
 
    ```yaml
    variables:

doc/ci/docker/using_docker_images.md

@@ -528,7 +528,7 @@ To access private container registries, the GitLab Runner process can use:
 To define which should be used, the GitLab Runner process reads the configuration in the following order:
 
 - `DOCKER_AUTH_CONFIG` variable provided as either:
-  - A [variable](../variables/README.md#gitlab-cicd-environment-variables) in `.gitlab-ci.yml`.
+  - A [variable](../variables/README.md) in `.gitlab-ci.yml`.
   - A project's variables stored on the projects **Settings > CI/CD** page.
 - `DOCKER_AUTH_CONFIG` variable provided as environment variable in `config.toml` of the runner.
 - `config.json` file placed in `$HOME/.docker` directory of the user running GitLab Runner process.
@@ -627,7 +627,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 [variable](../variables/README.md#gitlab-cicd-environment-variables) `DOCKER_AUTH_CONFIG` with the content of the
+1. Create a [variable](../variables/README.md) `DOCKER_AUTH_CONFIG` with the content of the
    Docker configuration file as the value:
 
    ```json
@@ -702,7 +702,7 @@ To configure credentials store, follow these steps:
 1. Make GitLab Runner use it. There are two ways to accomplish this. Either:
 
    - Create a
-     [variable](../variables/README.md#gitlab-cicd-environment-variables)
+     [variable](../variables/README.md)
      `DOCKER_AUTH_CONFIG` with the content of the
      Docker configuration file as the value:
 
@@ -734,7 +734,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 [variable](../variables/README.md#gitlab-cicd-environment-variables)
+   - Create a [variable](../variables/README.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
-[environment variables](../variables/README.md#predefined-environment-variables)
+[predefined CI/CD variables](../variables/README.md#predefined-cicd-variables)
 GitLab CI/CD provides.
 
 In the last step, kaniko uses the `Dockerfile` under the

doc/ci/environments/index.md

@@ -313,9 +313,9 @@ Dynamic environments are a fundamental part of [Review apps](../review_apps/inde
 The `name` and `url` keywords for dynamic environments can use most available CI/CD variables,
 including:
 
-- [Predefined environment variables](../variables/README.md#predefined-environment-variables)
-- [Project and group variables](../variables/README.md#gitlab-cicd-environment-variables)
-- [`.gitlab-ci.yml` variables](../yaml/README.md#variables)
+- [Predefined CI/CD variables](../variables/README.md#predefined-cicd-variables)
+- [Project and group CI/CD variables](../variables/README.md)
+- [`.gitlab-ci.yml` CI/CD variables](../yaml/README.md#variables)
 
 However, you cannot use variables defined:
 
@@ -1025,7 +1025,7 @@ with `review/` would have that particular variable.
 
 Some GitLab features can behave differently for each environment.
 For example, you can
-[create a secret variable to be injected only into a production environment](../variables/README.md#limit-the-environment-scopes-of-environment-variables).
+[create a secret variable to be injected only into a production environment](../variables/README.md#limit-the-environment-scopes-of-cicd-variables).
 
 In most cases, these features use the _environment specs_ mechanism, which offers
 an efficient way to implement scoping within each environment group.

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-environment-variables)
+a number of variables available](../../variables/README.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 [variable](../../variables/README.md#gitlab-cicd-environment-variables).
+Now, let's add it to your GitLab project as a [CI/CD variable](../../variables/README.md).
 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

@@ -150,9 +150,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 environment variables](../variables/README.md#custom-environment-variables).
+[custom environment variables](../variables/README.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-environment-variables),
+[the UI or `.gitlab-ci.yml`](../variables/README.md#custom-cicd-variables),
 for a single run of the manual job.
 
 ![Manual job variables](img/manual_job_variables.png)

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, [variables](../variables/README.md#group-level-environment-variables) 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, [variables](../variables/README.md#group-level-cicd-variables) can be stored outside the individual projects, and securely passed into pipelines across multiple projects.
 
 ## Orbs
 

doc/ci/multi_project_pipelines.md

@@ -220,7 +220,7 @@ the ones defined in the upstream project take precedence.
 
 #### With variable inheritance
 
-You can pass variables to a downstream pipeline with [`dotenv` variable inheritance](variables/README.md#inherit-environment-variables) 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/README.md#inherit-cicd-variables) and [cross project artifact downloads](yaml/README.md#cross-project-artifact-downloads-with-needs).
 
 In the upstream pipeline:
 

doc/ci/pipelines/index.md

@@ -77,7 +77,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-environment-variables).
+- [Custom CI/CD variables](../variables/README.md#custom-cicd-variables).
 
 ### Ref Specs for Runners
 

doc/ci/pipelines/settings.md

@@ -351,9 +351,9 @@ https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_te
 
 ![Badge with custom text and width](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130)
 
-## Environment Variables
+## CI/CD Variables
 
-[Environment variables](../variables/README.md#gitlab-cicd-environment-variables) can be set in an environment to be available to a runner.
+[CI/CD variables](../variables/README.md) can be set to be available to a runner.
 
 <!-- ## Troubleshooting
 

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 variables](../variables/README.md#custom-environment-variables)
+1. [Create the following CI variables](../variables/README.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 environment variable named `DATABASE_PASSWORD`,
-similar to [CI variables of type `file`](../variables/README.md#custom-environment-variables-of-type-file).
+similar to [CI variables of type `file`](../variables/README.md#custom-cicd-variables-of-type-file).
 
 For more information about the supported syntax, read the
 [`.gitlab-ci.yml` reference](../yaml/README.md#secretsvault).

doc/ci/ssh_keys/index.md

@@ -51,7 +51,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 [variable](../variables/README.md#gitlab-cicd-environment-variables).
+1. Create a new [CI/CD variable](../variables/README.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.
 
@@ -159,7 +159,7 @@ ssh-keyscan example.com
 ssh-keyscan 1.2.3.4
 ```
 
-Create a new [variable](../variables/README.md#gitlab-cicd-environment-variables) with
+Create a new [CI/CD variable](../variables/README.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/README.md

@@ -17,7 +17,7 @@ The following methods of authentication are supported:
 - [Trigger token](#trigger-token)
 - [CI job token](#ci-job-token)
 
-If using the `$CI_PIPELINE_SOURCE` [predefined environment variable](../variables/predefined_variables.md)
+If using the `$CI_PIPELINE_SOURCE` [predefined CI/CD variable](../variables/predefined_variables.md)
 to limit which jobs run in a pipeline, the value could be either `pipeline` or `trigger`,
 depending on which trigger method is used.
 
@@ -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 [variables](../variables/README.md#gitlab-cicd-environment-variables)
+their `.gitlab-ci.yml` file. Use [CI/CD variables](../variables/README.md)
 to protect trigger tokens.
 
 ### CI job token
 
-You can use the `CI_JOB_TOKEN` [variable](../variables/README.md#predefined-environment-variables) (used to authenticate
+You can use the `CI_JOB_TOKEN` [CI/CD variable](../variables/README.md#predefined-cicd-variables) (used to authenticate
 with the [GitLab Container Registry](../../user/packages/container_registry/index.md)) in the following cases.
 
 #### When used with multi-project pipelines
@@ -247,7 +247,7 @@ curl --request POST \
   "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
 ```
 
-Trigger variables have the [highest priority](../variables/README.md#priority-of-environment-variables)
+Trigger variables have the [highest priority](../variables/README.md#priority-of-cicd-variables)
 of all types of variables.
 
 ## Using cron to trigger nightly pipelines

doc/ci/variables/predefined_variables.md

@@ -5,19 +5,19 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Predefined environment variables reference
+# Predefined variables reference
 
 For an introduction on this subject, read through the
-[getting started with environment variables](README.md) document.
+[CI/CD variables](README.md) document.
 
-Some of the predefined environment variables are available only if a minimum
+Some of the predefined variables are available only if a minimum
 version of [GitLab Runner](https://docs.gitlab.com/runner/) is used. Consult the table below to find the
 version of GitLab Runner that's required.
 
 You can add a command to your `.gitlab-ci.yml` file to
 [output the values of all variables available for a job](README.md#list-all-environment-variables).
 
-Kubernetes-specific environment variables are detailed in the
+Kubernetes-specific variables are detailed in the
 [Kubernetes deployment variables](../../user/project/clusters/index.md#deployment-variables) section.
 
 | Variable                                      | GitLab | Runner | Description |

doc/ci/variables/where_variables_can_be_used.md

@@ -124,7 +124,7 @@ They are:
   - Script execution shell.
 - Not supported:
   - For definitions where the ["Expansion place"](#gitlab-ciyml-file) is GitLab.
-  - In the `only` and `except` [variables expressions](README.md#environment-variables-expressions).
+  - In the `only` and `except` [variables expressions](README.md#cicd-variable-expressions).
 
 Some of the persisted variables contain tokens and cannot be used by some definitions
 due to security reasons.

doc/ci/yaml/README.md

@@ -1212,13 +1212,13 @@ or excluded from a pipeline. In plain English, `if` rules can be interpreted as
 `rules:if` differs slightly from `only:variables` by accepting only a single
 expression string per rule, rather than an array of them. Any set of expressions to be
 evaluated can be [conjoined into a single expression](../variables/README.md#conjunction--disjunction)
-by using `&&` or `||`, and the [variable matching operators (`==`, `!=`, `=~` and `!~`)](../variables/README.md#syntax-of-environment-variable-expressions).
+by using `&&` or `||`, and the [variable matching operators (`==`, `!=`, `=~` and `!~`)](../variables/README.md#syntax-of-cicd-variable-expressions).
 
-Unlike variables in [`script`](../variables/README.md#syntax-of-environment-variables-in-job-scripts)
+Unlike variables in [`script`](../variables/README.md#syntax-of-cicd-variables-in-job-scripts)
 sections, variables in rules expressions are always formatted as `$VARIABLE`.
 
 `if:` clauses are evaluated based on the values of [predefined environment variables](../variables/predefined_variables.md)
-or [custom environment variables](../variables/README.md#custom-environment-variables).
+or [custom environment variables](../variables/README.md#custom-cicd-variables).
 
 For example:
 
@@ -1303,7 +1303,7 @@ Other commonly used variables for `if` clauses:
   branch (usually `master`). 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-environment-variables)
+- `if: '$CUSTOM_VARIABLE !~ /regex-expression/'`: If the [custom variable](../variables/README.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`.
@@ -3577,7 +3577,7 @@ test:
 ```
 
 Every parallel job has a `CI_NODE_INDEX` and `CI_NODE_TOTAL`
-[environment variable](../variables/README.md#predefined-environment-variables) set.
+[environment variable](../variables/README.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)
@@ -3616,7 +3616,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` [environment variable](../variables/README.md#predefined-environment-variables) value, and a unique `CI_NODE_INDEX` value.
+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.
 
 ```yaml
 deploystacks:
@@ -4290,7 +4290,7 @@ They can be set globally and per-job.
 
 There are two types of variables.
 
-- [Custom variables](../variables/README.md#custom-environment-variables):
+- [Custom variables](../variables/README.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).
@@ -4326,7 +4326,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#priority-of-environment-variables).
+[job-specific variable overrides the global variable](../variables/README.md#priority-of-cicd-variables).
 
 All YAML-defined variables are also set to any linked
 [Docker service containers](../docker/using_docker_images.md#what-is-a-service).

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 variables, or even [custom environment variables](../variables/README.md#custom-environment-variables),
+You can define the color codes in Shell variables, or even [custom environment variables](../variables/README.md#custom-cicd-variables),
 which makes the commands easier to read and reusable.
 
 For example, using the same example as above and variables defined in a `before_script`:

doc/development/gitaly.md

@@ -211,9 +211,9 @@ and specify it in the URL:
 GITALY_REPO_URL=https://gitlab+deploy-token-1000:token-here@gitlab.com/nick.thomas/gitaly bundle exec rspec spec/lib/gitlab/git/repository_spec.rb
 ```
 
-To use a custom Gitaly repository in CI, for instance if you want your
+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 environment variable](../ci/variables/README.md#gitlab-cicd-environment-variables).
+as a [CI/CD variable](../ci/variables/README.md).
 
 ### Use a locally modified version of Gitaly RPC client
 

doc/raketasks/backup_restore.md

@@ -810,7 +810,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#gitlab-cicd-environment-variables), and
+[CI/CD variables](../ci/variables/README.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

doc/topics/autodevops/customize.md

@@ -136,7 +136,7 @@ repository or by specifying a project 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 variable](../../ci/variables/README.md#gitlab-cicd-environment-variables)
+- **Project variable** - Create a [project CI/CD variable](../../ci/variables/README.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.
@@ -171,7 +171,7 @@ list of options.
 ## Custom Helm chart per environment
 
 You can specify the use of a custom Helm chart per environment by scoping the environment variable
-to the desired environment. See [Limiting environment scopes of variables](../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables).
+to the desired environment. See [Limiting environment scopes of variables](../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables).
 
 ## Customizing `.gitlab-ci.yml`
 
@@ -357,7 +357,7 @@ applications.
 
 NOTE:
 After you set up your replica variables using a
-[project variable](../../ci/variables/README.md#gitlab-cicd-environment-variables),
+[project CI/CD variable](../../ci/variables/README.md),
 you can scale your application by redeploying it.
 
 WARNING:
@@ -376,7 +376,7 @@ The following table lists 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-environment-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/README.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

@@ -166,7 +166,7 @@ any of the following places:
   **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#priority-of-environment-variables).
+as other environment [variables](../../ci/variables/README.md#priority-of-cicd-variables).
 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.
 
@@ -286,7 +286,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-scopes-of-environment-variables).
+[based on the environment](../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables).
 
 The following table is an example of how to configure the three different clusters:
 

doc/user/application_security/api_fuzzing/index.md

@@ -599,7 +599,7 @@ variables:
 ```
 
 In this example `.gitlab-ci.yml`, the CI/CD variable `SECRET_OVERRIDES` provides the JSON. This is a
-[group or instance level environment variable defined in the UI](../../../ci/variables/README.md#instance-level-cicd-environment-variables):
+[group or instance level environment variable defined in the UI](../../../ci/variables/README.md#instance-level-cicd-variables):
 
 ```yaml
 include:

doc/user/application_security/index.md

@@ -549,7 +549,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 environment variable](../../ci/variables/README.md#custom-environment-variables).
+[custom environment variable](../../ci/variables/README.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

@@ -152,7 +152,7 @@ GitLab.com. To do so, set the environment variable `SECURE_ANALYZERS_PREFIX` wit
 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 environment variables page](../../../ci/variables/README.md#custom-environment-variables)
+in the GitLab UI at the project or group level. See the [GitLab CI/CD environment variables page](../../../ci/variables/README.md#custom-cicd-variables)
 for more information.
 
 #### Variables

doc/user/application_security/sast/index.md

@@ -489,7 +489,7 @@ Some analyzers can be customized with environment variables.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18193) in GitLab Ultimate 12.5.
 
 In addition to the aforementioned SAST configuration variables,
-all [custom environment variables](../../../ci/variables/README.md#custom-environment-variables) are propagated
+all [custom CI/CD variables](../../../ci/variables/README.md#custom-cicd-variables) are propagated
 to the underlying SAST analyzer images if
 [the SAST vendored template](#configuration) is used.
 

doc/user/compliance/license_compliance/index.md

@@ -367,7 +367,7 @@ source "https://gems.example.com"
 You can supply a custom root certificate to complete TLS verification by using the
 `ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables), or by
 specifying a [`BUNDLE_SSL_CA_CERT`](https://bundler.io/v2.0/man/bundle-config.1.html)
-[environment variable](../../../ci/variables/README.md#custom-environment-variables)
+[environment variable](../../../ci/variables/README.md#custom-cicd-variables)
 in the job definition.
 
 ### Configuring Cargo projects
@@ -391,7 +391,7 @@ To supply a custom root certificate to complete TLS verification, do one of the
 
 - Use the `ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables).
 - Specify a [`CARGO_HTTP_CAINFO`](https://doc.rust-lang.org/cargo/reference/environment-variables.html)
-  [environment variable](../../../ci/variables/README.md#custom-environment-variables)
+  [environment variable](../../../ci/variables/README.md#custom-cicd-variables)
   in the job definition.
 
 ### Configuring Composer projects
@@ -424,7 +424,7 @@ For example:
 You can supply a custom root certificate to complete TLS verification by using the
 `ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables), or by
 specifying a [`COMPOSER_CAFILE`](https://getcomposer.org/doc/03-cli.md#composer-cafile)
-[environment variable](../../../ci/variables/README.md#custom-environment-variables)
+[environment variable](../../../ci/variables/README.md#custom-cicd-variables)
 in the job definition.
 
 ### Configuring Conan projects

doc/user/group/clusters/index.md

@@ -107,7 +107,7 @@ The domain should have a wildcard DNS configured to the Ingress IP address.
 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 variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables)
+[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables)
 work.
 
 While evaluating which environment matches the environment scope of a

doc/user/packages/dependency_proxy/index.md

@@ -119,7 +119,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 environment variables](../../../ci/variables/README.md#custom-environment-variables) to store and access your personal access token or other valid credentials.
+You can also use [custom environment variables](../../../ci/variables/README.md#custom-cicd-variables) to store and access your personal access token or other valid credentials.
 
 ### Store a Docker image in Dependency Proxy cache
 

doc/user/packages/maven_repository/index.md

@@ -756,7 +756,7 @@ The next time the `deploy` job runs, it copies `ci_settings.xml` to the
 user's home location. In this example:
 
 - The user is `root`, because the job runs in a Docker container.
-- Maven uses the configured CI [environment variables](../../../ci/variables/README.md#predefined-environment-variables).
+- Maven uses the configured CI [environment variables](../../../ci/variables/README.md#predefined-cicd-variables).
 
 ### Create Maven packages with GitLab CI/CD by using Gradle
 

doc/user/project/clusters/index.md

@@ -87,7 +87,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 variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables) work.
+[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables) 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
@@ -289,7 +289,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 [environment variables](../../../ci/variables/README.md#custom-environment-variables)
+  using [environment variables](../../../ci/variables/README.md#custom-cicd-variables)
   before you can interact with the cluster from your jobs.
 
 ### Deployment variables
@@ -311,7 +311,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-environment-variables) in the
+[deployment variables](../../../ci/variables/README.md#deployment-variables) in the
 GitLab CI/CD build environment to deployment jobs. Deployment jobs have
 [defined a target environment](../../../ci/environments/index.md#defining-environments).
 

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-environment-variables),
+[`$CI_ENVIRONMENT_SLUG`](../../../../ci/variables/README.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-environment-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/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.
 
 ## Displaying Canary metrics **(PREMIUM)**
 

doc/user/project/new_ci_build_permissions_model.md

@@ -195,7 +195,7 @@ As a user:
 
 ### Dependent repositories
 
-The [Job environment variable](../../ci/variables/README.md#predefined-environment-variables) `CI_JOB_TOKEN` can be used to
+The [CI/CD variable](../../ci/variables/README.md#predefined-cicd-variables) `CI_JOB_TOKEN` can be used to
 authenticate any clones of dependent repositories. For example:
 
 ```shell