Change usage of CI variables terminology

We should talk about CI/CD variables, not environment
variables, when talking about variables used in CI/CD

doc/ci/README.md

@@ -90,7 +90,7 @@ GitLab CI/CD uses a number of concepts to describe and run your build and deploy
 | Concept                                                 | Description                                                                    |
 |:--------------------------------------------------------|:-------------------------------------------------------------------------------|
 | [Pipelines](pipelines/index.md)                         | Structure your CI/CD process through pipelines.                                |
-| [Environment variables](variables/README.md)            | Reuse values based on a variable/value key pair.                               |
+| [CI/CD variables](variables/README.md)                  | Reuse values based on a variable/value key pair.                               |
 | [Environments](environments/index.md)                   | Deploy your application to different environments (e.g., staging, production). |
 | [Job artifacts](pipelines/job_artifacts.md)             | Output, use, and reuse job artifacts.                                          |
 | [Cache dependencies](caching/index.md)                  | Cache your dependencies for a faster execution.                                |

doc/ci/ci_cd_for_external_repos/bitbucket_integration.md

@@ -50,7 +50,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
 
    ![Bitbucket Cloud webhook](img/bitbucket_app_password.png)
 
-1. In GitLab, from **Settings > CI/CD > Environment variables**, add variables to allow
+1. In GitLab, from **Settings > CI/CD > Variables**, add variables to allow
    communication with Bitbucket via the Bitbucket API:
 
    `BITBUCKET_ACCESS_TOKEN`: the Bitbucket app password created above.

doc/ci/cloud_deployment/index.md

@@ -109,7 +109,7 @@ The ECS task definition can be:
 
 After you have these prerequisites ready, follow these steps:
 
-1. Make sure your AWS credentials are set up as environment variables for your
+1. Make sure your AWS credentials are set up as CI/CD variables for your
    project. You can follow [the steps above](#run-aws-commands-from-gitlab-cicd) to complete this setup.
 1. Add these variables to your project's `.gitlab-ci.yml` file, or in the project's
    [CI/CD settings](../variables/README.md#create-a-custom-variable-in-the-ui):
@@ -242,7 +242,7 @@ pass three JSON input objects, based on existing templates:
    have two ways to pass in these JSON objects:
 
    - They can be three actual files located in your project. You must specify their path relative to
-     your project root in your `.gitlab-ci.yml` file, using the following variables. For example, if
+     your project root in your `.gitlab-ci.yml` file, using the following CI/CD variables. For example, if
      your files are in a `<project_root>/aws` folder:
 
      ```yaml
@@ -286,7 +286,7 @@ When running your project pipeline at this point:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216008) in GitLab 13.6.
 
 To leverage [Auto DevOps](../../topics/autodevops/index.md) for your project when deploying to
-AWS EC2, first you must define [your AWS credentials as environment variables](#run-aws-commands-from-gitlab-cicd).
+AWS EC2, first you must define [your AWS credentials as CI/CD variables](#run-aws-commands-from-gitlab-cicd).
 
 Next, define a job for the `build` stage. To do so, you must reference the
 `Auto-DevOps.gitlab-ci.yml` template and include a job named `build_artifact` in your

doc/ci/docker/using_docker_build.md

@@ -830,7 +830,7 @@ which can be avoided if a different driver is used, for example `overlay2`.
 ### Use the OverlayFS driver per project
 
 You can enable the driver for each project individually by using the `DOCKER_DRIVER`
-environment [variable](../yaml/README.md#variables) in `.gitlab-ci.yml`:
+[CI/CD variable](../yaml/README.md#variables) in `.gitlab-ci.yml`:
 
 ```yaml
 variables:

doc/ci/docker/using_docker_images.md

@@ -272,11 +272,11 @@ test:
     - bundle exec rake spec
 ```
 
-## Passing environment variables to services
+## Passing CI/CD variables to services
 
-You can also pass custom environment [variables](../variables/README.md)
+You can also pass custom CI/CD [variables](../variables/README.md)
 to fine tune your Docker `images` and `services` directly in the `.gitlab-ci.yml` file.
-For more information, read [custom environment variables](../variables/README.md#gitlab-ciyml-defined-variables)
+For more information, read about [`.gitlab-ci.yml` defined variables](../variables/README.md#gitlab-ciyml-defined-variables).
 
 ```yaml
 # The following variables are automatically passed down to the Postgres container
@@ -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) in `.gitlab-ci.yml`.
+  - A [CI/CD 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) `DOCKER_AUTH_CONFIG` with the content of the
+1. Create a [CI/CD 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)
+     [CI/CD 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)
+   - Create a [CI/CD variable](../variables/README.md)
      `DOCKER_AUTH_CONFIG` with the content of the
      Docker configuration file as the value:
 
@@ -781,13 +781,13 @@ registries to the `"credHelpers"` hash as described above.
 Many services accept environment variables, which you can use to change
 database names or set account names, depending on the environment.
 
-GitLab Runner 0.5.0 and up passes all YAML-defined variables to the created
+GitLab Runner 0.5.0 and up passes all YAML-defined CI/CD variables to the created
 service containers.
 
 For all possible configuration variables, check the documentation of each image
 provided in their corresponding Docker hub page.
 
-All variables are passed to all services containers. It's not
+All CI/CD variables are passed to all services containers. It's not
 designed to distinguish which variable should go where.
 
 ### PostgreSQL service example

doc/ci/environments/deployment_safety.md

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

doc/ci/environments/index.md

@@ -135,12 +135,12 @@ In summary, with the above `.gitlab-ci.yml` we have achieved the following:
   job deploys our code to a staging server while the deployment
   is recorded in an environment named `staging`.
 
-#### Environment variables and runners
+#### CI/CD variables and runners
 
 Starting with GitLab 8.15, the environment name is exposed to the runner in
 two forms:
 
-- `$CI_ENVIRONMENT_NAME`. The name given in `.gitlab-ci.yml` (with any variables
+- `$CI_ENVIRONMENT_NAME`. The name given in `.gitlab-ci.yml` (with any CI/CD variables
   expanded).
 - `$CI_ENVIRONMENT_SLUG`. A "cleaned-up" version of the name, suitable for use in URLs,
   DNS, etc.
@@ -221,7 +221,7 @@ The assigned URL for the `review/your-branch-name` environment is [visible in th
 Note the following:
 
 - `stop_review` doesn't generate a dotenv report artifact, so it doesn't recognize the
-  `DYNAMIC_ENVIRONMENT_URL` variable. Therefore you shouldn't set `environment:url:` in the
+  `DYNAMIC_ENVIRONMENT_URL` environment variable. Therefore you shouldn't set `environment:url:` in the
   `stop_review` job.
 - If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update
   the environment URL.
@@ -327,7 +327,7 @@ For more information, see [Where variables can be used](../variables/where_varia
 
 #### Example configuration
 
-Runners expose various [environment variables](../variables/README.md) when a job runs, so
+Runners expose various [predefined CI/CD variables](../variables/predefined_variables.md) when a job runs, so
 you can use them as environment names.
 
 In the following example, the job deploys to all branches except `master`:
@@ -825,7 +825,7 @@ build with the specified environment runs. Newer deployments can also
 
 You may want to specify an environment keyword to
 [protect builds from unauthorized access](protected_environments.md), or to get
-access to [scoped variables](#scoping-environments-with-specs). In these cases,
+access to [environment-scoped variables](#scoping-environments-with-specs). In these cases,
 you can use the `action: prepare` keyword to ensure deployments aren't created,
 and no builds are canceled:
 
@@ -846,7 +846,7 @@ build:
 
 As documented in [Configuring dynamic environments](#configuring-dynamic-environments), you can
 prepend environment name with a word, followed by a `/`, and finally the branch
-name, which is automatically defined by the `CI_COMMIT_REF_NAME` variable.
+name, which is automatically defined by the `CI_COMMIT_REF_NAME` predefined CI/CD variable.
 
 In short, environments that are named like `type/foo` are all presented under the same
 group, named `type`.
@@ -1009,9 +1009,9 @@ fetch = +refs/environments/*:refs/remotes/origin/environments/*
 ### Scoping environments with specs
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2112) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.4.
-> - [Scoping for environment variables was moved to Free](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30779) in GitLab 12.2.
+> - [Environment scoping for CI/CD variables was moved to all tiers](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30779) in GitLab 12.2.
 
-You can limit the environment scope of a variable by
+You can limit the environment scope of a CI/CD variable by
 defining which environments it can be available for.
 
 Wildcards can be used and the default environment scope is `*`. This means that
@@ -1061,7 +1061,7 @@ environment's operational health.
 
 ## Limitations
 
-In the `environment: name`, you are limited to only the [predefined environment variables](../variables/predefined_variables.md).
+In the `environment: name`, you are limited to only the [predefined CI/CD variables](../variables/predefined_variables.md).
 Re-using variables defined inside `script` as part of the environment name doesn't work.
 
 ## Further reading

doc/ci/examples/authenticating-with-hashicorp-vault/index.md

@@ -30,7 +30,7 @@ You must replace the `vault.example.com` URL below with the URL of your Vault se
 
 ## How it works
 
-Each job has JSON Web Token (JWT) provided as environment variable named `CI_JOB_JWT`. This JWT can be used to authenticate with Vault using the [JWT Auth](https://www.vaultproject.io/docs/auth/jwt#jwt-authentication) method.
+Each job has JSON Web Token (JWT) provided as CI/CD variable named `CI_JOB_JWT`. This JWT can be used to authenticate with Vault using the [JWT Auth](https://www.vaultproject.io/docs/auth/jwt#jwt-authentication) method.
 
 The JWT's payload looks like this:
 
@@ -187,7 +187,7 @@ read_secrets:
     - echo $CI_COMMIT_REF_NAME
     # and is this ref protected
     - echo $CI_COMMIT_REF_PROTECTED
-    # Vault's address can be provided here or as CI variable
+    # Vault's address can be provided here or as CI/CD variable
     - export VAULT_ADDR=http://vault.example.com:8200
     # Authenticate and get token. Token expiry time and other properties can be configured
     # when configuring JWT Auth - https://www.vaultproject.io/api/auth/jwt#parameters-1
@@ -211,7 +211,7 @@ read_secrets:
     - echo $CI_COMMIT_REF_NAME
     # and is this ref protected
     - echo $CI_COMMIT_REF_PROTECTED
-    # Vault's address can be provided here or as CI variable
+    # Vault's address can be provided here or as CI/CD variable
     - export VAULT_ADDR=http://vault.example.com:8200
     # Authenticate and get token. Token expiry time and other properties can be configured
     # when configuring JWT Auth - https://www.vaultproject.io/api/auth/jwt#parameters-1

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -120,7 +120,7 @@ cat ~/.ssh/id_rsa
 ```
 
 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.
+Project CI/CD variables are user-defined variables and are stored out of `.gitlab-ci.yml`, for security purposes.
 They can be added per project by navigating to the project's **Settings** > **CI/CD**.
 
 To the field **KEY**, add the name `SSH_PRIVATE_KEY`, and to the **VALUE** field, paste the private key you've copied earlier.
@@ -546,9 +546,9 @@ services:
 
 If you wish to test your app with different PHP versions and [database management systems](../../services/index.md), you can define different `image` and `services` keywords for each test job.
 
-#### Variables
+#### CI/CD variables
 
-GitLab CI/CD allows us to use [environment variables](../../yaml/README.md#variables) in our jobs.
+GitLab CI/CD allows us to use [CI/CD variables](../../yaml/README.md#variables) in our jobs.
 We defined MySQL as our database management system, which comes with a superuser root created by default.
 
 So we should adjust the configuration of MySQL instance by defining `MYSQL_DATABASE` variable as our database name and `MYSQL_ROOT_PASSWORD` variable as the password of `root`.
@@ -567,7 +567,7 @@ variables:
 
 #### Unit Test as the first job
 
-We defined the required shell scripts as an array of the [script](../../yaml/README.md#script) variable to be executed when running `unit_test` job.
+We defined the required shell scripts as an array of the [script](../../yaml/README.md#script) keyword to be executed when running `unit_test` job.
 
 These scripts are some Artisan commands to prepare the Laravel, and, at the end of the script, we'll run the tests by `PHPUnit`.
 

doc/ci/examples/test-and-deploy-python-application-to-heroku.md

@@ -59,7 +59,7 @@ This project has three jobs:
 
 ## Store API keys
 
-You'll need to create two variables in **Settings > CI/CD > Environment variables** in your GitLab project:
+You'll need to create two variables in **Settings > CI/CD > Variables** in your GitLab project:
 
 - `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app.
 - `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.

doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md

@@ -50,7 +50,7 @@ This project has three jobs:
 
 ## Store API keys
 
-You'll need to create two variables in your project's **Settings > CI/CD > Environment variables** and do not check **Protect variable** and **Mask variable**:
+You'll need to create two CI/CD variables in your project's **Settings > CI/CD > Variables** and do not check **Protect variable** or **Mask variable**:
 
 - `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app.
 - `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.

doc/ci/jobs/index.md

@@ -150,7 +150,7 @@ 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-cicd-variables).
+[custom CI/CD 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-cicd-variables),
 for a single run of the manual job.

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-cicd-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, [CI/CD 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

@@ -68,7 +68,7 @@ outbound connections for upstream and downstream pipeline dependencies.
 
 When using:
 
-- Variables or [`rules`](yaml/README.md#rulesif) to control job behavior, the value of
+- CI/CD Variables or [`rules`](yaml/README.md#rulesif) to control job behavior, the value of
   the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md) is
   `pipeline` for multi-project pipeline triggered through the API with `CI_JOB_TOKEN`.
 - [`only/except`](yaml/README.md#onlyexcept-basic) to control job behavior, use the
@@ -114,7 +114,7 @@ the `staging` job is marked as _failed_.
 
 When using:
 
-- Variables or [`rules`](yaml/README.md#rulesif) to control job behavior, the value of
+- CI/CD variables or [`rules`](yaml/README.md#rulesif) to control job behavior, the value of
   the [`$CI_PIPELINE_SOURCE` predefined variable](variables/predefined_variables.md) is
   `pipeline` for multi-project pipelines triggered with a bridge job (using the
   [`trigger:`](yaml/README.md#trigger) keyword).
@@ -162,11 +162,11 @@ of the user that ran the trigger job in the upstream project. If the user does n
 have permission to run CI/CD pipelines against the protected branch, the pipeline fails. See
 [pipeline security for protected branches](pipelines/index.md#pipeline-security-on-protected-branches).
 
-### Passing variables to a downstream pipeline
+### Passing CI/CD variables to a downstream pipeline
 
 #### With the `variables` keyword
 
-Sometimes you might want to pass variables to a downstream pipeline.
+Sometimes you might want to pass CI/CD variables to a downstream pipeline.
 You can do that using the `variables` keyword, just like you would when
 defining a regular job.
 
@@ -183,7 +183,7 @@ staging:
 ```
 
 The `ENVIRONMENT` variable is passed to every job defined in a downstream
-pipeline. It is available as an environment variable when GitLab Runner picks a job.
+pipeline. It is available as a variable when GitLab Runner picks a job.
 
 In the following configuration, the `MY_VARIABLE` variable is passed to the downstream pipeline
 that is created when the `trigger-downstream` job is queued. This is because `trigger-downstream`

doc/ci/parent_child_pipelines.md

@@ -183,7 +183,7 @@ possible to trigger another level of child pipelines.
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For an overview, see [Nested Dynamic Pipelines](https://youtu.be/C5j3ju9je2M).
 
-## Pass variables to a child pipeline
+## Pass CI/CD variables to a child pipeline
 
-You can [pass variables to a downstream pipeline](multi_project_pipelines.md#passing-variables-to-a-downstream-pipeline)
+You can [pass CI/CD variables to a downstream pipeline](multi_project_pipelines.md#passing-cicd-variables-to-a-downstream-pipeline)
 the same way as for multi-project pipelines.

doc/ci/pipelines/job_artifacts.md

@@ -498,7 +498,7 @@ This is often preceded by other errors or warnings that specify the filename and
 generated in the first place. Please check the entire job log for such messages.
 
 If you find no helpful messages, please retry the failed job after activating
-[CI debug logging](../variables/README.md#debug-logging).
+[CI/CD debug logging](../variables/README.md#debug-logging).
 This provides useful information to investigate further.
 
 <!-- ## Troubleshooting

doc/ci/review_apps/index.md

@@ -58,7 +58,7 @@ The process of configuring Review Apps is as follows:
 
 1. Set up the infrastructure to host and deploy the Review Apps (check the [examples](#review-apps-examples) below).
 1. [Install](https://docs.gitlab.com/runner/install/) and [configure](https://docs.gitlab.com/runner/commands/) a runner to do deployment.
-1. Set up a job in `.gitlab-ci.yml` that uses the [predefined CI environment variable](../variables/README.md) `${CI_COMMIT_REF_NAME}`
+1. Set up a job in `.gitlab-ci.yml` that uses the [predefined CI/CD variable](../variables/README.md) `${CI_COMMIT_REF_NAME}`
    to create dynamic environments and restrict it to run only on branches.
    Alternatively, you can get a YML template for this job by [enabling review apps](#enable-review-apps-button) for your project.
 1. Optionally, set a job that [manually stops](../environments/index.md#stopping-an-environment) the Review Apps.
@@ -243,7 +243,7 @@ looks for a project with code hosted in a project on GitLab.com:
 </script>
 ```
 
-Ideally, you should use [environment variables](../variables/predefined_variables.md)
+Ideally, you should use [CI/CD variables](../variables/predefined_variables.md)
 to replace those values at runtime when each review app is created:
 
 - `data-project-id` is the project ID, which can be found by the `CI_PROJECT_ID`

doc/ci/secrets/index.md

@@ -13,7 +13,7 @@ Secrets represent sensitive information your CI job needs to complete work. This
 sensitive information can be items like API tokens, database credentials, or private keys.
 Secrets are sourced from your secrets provider.
 
-Unlike CI variables, which are always presented to a job, secrets must be explicitly
+Unlike CI/CD variables, which are always presented to a job, secrets must be explicitly
 required by a job. Read [GitLab CI/CD pipeline configuration reference](../yaml/README.md#secrets)
 for more information about the syntax.
 
@@ -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-cicd-variables)
+1. [Create the following CI/CD 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.
@@ -113,8 +113,8 @@ In this example:
 - `ops` - The path where the secrets engine is mounted.
 
 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-cicd-variables-of-type-file).
+The path to this file is stored in a CI/CD variable named `DATABASE_PASSWORD`,
+similar to [variables of type `file`](../variables/README.md#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/services/mysql.md

@@ -14,7 +14,7 @@ need it for your tests to run.
 
 If you want to use a MySQL container, you can use [GitLab Runner](../runners/README.md) with the Docker executor.
 
-1. [Create variables](../variables/README.md#create-a-custom-variable-in-the-ui) for your
+1. [Create CI/CD variables](../variables/README.md#create-a-custom-variable-in-the-ui) for your
    MySQL database and password by going to **Settings > CI/CD**, expanding **Variables**,
    and clicking **Add Variable**.
 

doc/ci/services/postgres.md

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

doc/ci/variables/README.md

@@ -604,7 +604,7 @@ You can override the value of a variable when:
 1. Manually playing a job via the UI.
 1. Using [push options](../../user/project/push_options.md#push-options-for-gitlab-cicd).
 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).
+1. Passing variables to a [downstream pipeline](../multi_project_pipelines.md#passing-cicd-variables-to-a-downstream-pipeline).
 
 These pipeline variables declared in these events take [priority over other variables](#priority-of-cicd-variables).
 

doc/ci/yaml/README.md

@@ -396,7 +396,7 @@ include:
 ```
 
 For an example of how you can include these predefined variables, and their impact on CI jobs,
-see the following [CI variable demo](https://youtu.be/4XR8gw3Pkos).
+see the following [CI/CD variable demo](https://youtu.be/4XR8gw3Pkos).
 
 #### `include:local`
 
@@ -1217,8 +1217,8 @@ by using `&&` or `||`, and the [variable matching operators (`==`, `!=`, `=~` an
 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-cicd-variables).
+`if:` clauses are evaluated based on the values of [predefined CI/CD variables](../variables/predefined_variables.md)
+or [custom CI/CD variables](../variables/README.md#custom-cicd-variables).
 
 For example:
 
@@ -1359,7 +1359,7 @@ if there is no `if:` statement that limits the job to branch or merge request pi
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34272) in GitLab 13.6.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/267192) in GitLab 13.7.
 
-Environment variables can be used in `rules:changes` expressions to determine when
+CI/CD variables can be used in `rules:changes` expressions to determine when
 to add jobs to a pipeline:
 
 ```yaml
@@ -2143,7 +2143,7 @@ build_job:
       artifacts: true
 ```
 
-Environment variables support for `project:`, `job:`, and `ref` was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202093)
+CI/CD variable support for `project:`, `job:`, and `ref` was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202093)
 in GitLab 13.3. [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/235761) in GitLab 13.4.
 
 For example:
@@ -2711,7 +2711,7 @@ deploy as review app:
 
 The `deploy as review app` job is marked as a deployment to dynamically
 create the `review/$CI_COMMIT_REF_NAME` environment. `$CI_COMMIT_REF_NAME`
-is an [environment variable](../variables/README.md) set by the runner. The
+is a [CI/CD variable](../variables/README.md) set by the runner. The
 `$CI_ENVIRONMENT_SLUG` variable is based on the environment name, but suitable
 for inclusion in URLs. If the `deploy as review app` job runs in a branch named
 `pow`, this environment would be accessible with a URL like `https://review-pow.example.com/`.
@@ -3577,7 +3577,7 @@ test:
 ```
 
 Every parallel job has a `CI_NODE_INDEX` and `CI_NODE_TOTAL`
-[environment variable](../variables/README.md#predefined-cicd-variables) set.
+[predefined CI/CD 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)
@@ -4207,10 +4207,10 @@ release-cli create --name "Release $CI_COMMIT_SHA" --description "Created using
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33014) in GitLab 13.4.
 
-`secrets` indicates the [CI Secrets](../secrets/index.md) this job needs. It should be a hash,
-and the keys should be the names of the environment variables that are made available to the job.
+`secrets` indicates the [CI/CD Secrets](../secrets/index.md) this job needs. It should be a hash,
+and the keys should be the names of the variables that are made available to the job.
 The value of each secret is saved in a temporary file. This file's path is stored in these
-environment variables.
+variables.
 
 #### `secrets:vault` **(PREMIUM)**