Update more variables to CI/CD variables

We need to ensure consistent use of CI/CD variable
terminology, and avoid using Environment unless its
 specifically about environments.

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-cicd-variables),
+You can define the color codes in Shell variables, or even [custom CI/CD 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/user/infrastructure/terraform_state.md

@@ -116,7 +116,7 @@ and the CI YAML file:
    image: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
    ```
 
-1. In the `.gitlab-ci.yml` file, define some environment variables to ease
+1. In the `.gitlab-ci.yml` file, define some CI/CD variables to ease
    development. In this example, `TF_ROOT` is the directory where the Terraform
    commands must be executed, `TF_ADDRESS` is the URL to the state on the GitLab
    instance where this pipeline runs, and the final path segment in `TF_ADDRESS`
@@ -212,7 +212,7 @@ as [Terraform input variables](https://www.terraform.io/docs/configuration/varia
 - **username**: The username to authenticate with the data source. If you are using a [Personal Access Token](../profile/personal_access_tokens.md) for
   authentication, this is your GitLab username. If you are using GitLab CI, this is `'gitlab-ci-token'`.
 - **password**: The password to authenticate with the data source. If you are using a Personal Access Token for
-  authentication, this is the token value. If you are using GitLab CI, it is the contents of the `${CI_JOB_TOKEN}` CI variable.
+  authentication, this is the token value. If you are using GitLab CI, it is the contents of the `${CI_JOB_TOKEN}` CI/CD variable.
 
 An example setup is shown below:
 

doc/user/project/clusters/index.md

@@ -86,7 +86,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-cicd-variables) work.
+[environment-specific CI/CD 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
@@ -200,7 +200,7 @@ To clear the cache:
 You do not need to specify a base domain on cluster settings when using GitLab Serverless. The domain in that case
 is specified as part of the Knative installation. See [Installing Applications](#installing-applications).
 
-Specifying a base domain automatically sets `KUBE_INGRESS_BASE_DOMAIN` as an environment variable.
+Specifying a base domain automatically sets `KUBE_INGRESS_BASE_DOMAIN` as an deployment variable.
 If you are using [Auto DevOps](../../../topics/autodevops/index.md), this domain is used for the different
 stages. For example, Auto Review Apps and Auto Deploy.
 
@@ -288,7 +288,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-cicd-variables)
+  using [CI/CD variables](../../../ci/variables/README.md#custom-cicd-variables)
   before you can interact with the cluster from your jobs.
 
 ### Deployment variables
@@ -314,7 +314,7 @@ The Kubernetes cluster integration exposes these
 GitLab CI/CD build environment to deployment jobs. Deployment jobs have
 [defined a target environment](../../../ci/environments/index.md#defining-environments).
 
-| Variable                   | Description |
+| Deployment Variable        | Description |
 |----------------------------|-------------|
 | `KUBE_URL`                 | Equal to the API URL. |
 | `KUBE_TOKEN`               | The Kubernetes token of the [environment service account](add_remove_clusters.md#access-controls). Prior to GitLab 11.5, `KUBE_TOKEN` was the Kubernetes token of the main service account of the cluster integration. |
@@ -352,7 +352,7 @@ When you customize the namespace, existing environments remain linked to their c
 namespaces until you [clear the cluster cache](#clearing-the-cluster-cache).
 
 WARNING:
-By default, anyone who can create a deployment job can access any CI variable in
+By default, anyone who can create a deployment job can access any CI/CD variable in
 an environment's deployment job. This includes `KUBECONFIG`, which gives access to
 any secret available to the associated service account in your cluster.
 To keep your production credentials safe, consider using
@@ -406,7 +406,7 @@ deployments, replica sets, and pods are annotated with:
 - `app.gitlab.com/app: $CI_PROJECT_PATH_SLUG`
 
 `$CI_ENVIRONMENT_SLUG` and `$CI_PROJECT_PATH_SLUG` are the values of
-the CI variables.
+the CI/CD variables.
 
 You must be the project owner or have `maintainer` permissions to use terminals.
 Support is limited to the first container in the first pod of your environment.
@@ -431,7 +431,7 @@ Reasons for failure include:
 
 - The token you gave GitLab does not have [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
   privileges required by GitLab.
-- Missing `KUBECONFIG` or `KUBE_TOKEN` variables. To be passed to your job, they must have a matching
+- Missing `KUBECONFIG` or `KUBE_TOKEN` deployment variables. To be passed to your job, they must have a matching
   [`environment:name`](../../../ci/environments/index.md#defining-environments). If your job has no
   `environment:name` set, the Kubernetes credentials are not passed to it.
 

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

@@ -367,8 +367,7 @@ sam init -h
 ### Setting up your AWS credentials with your GitLab account
 
 In order to interact with your AWS account, the GitLab CI/CD pipelines require both
-`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be set in the project's CI/CD
-variables.
+`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be set in the project's CI/CD variables.
 
 To set these:
 
@@ -424,8 +423,8 @@ deploys your application. If your:
   - Incompatible versions of software. For example, Python runtime version might be
     different from the Python on the build machine. Address this by installing the
     required versions of the software.
-  - You may not be able to access your AWS account from GitLab. Check the environment
-    variables you set up with AWS credentials.
+  - You may not be able to access your AWS account from GitLab. Check the CI/CD variables
+    you set up with AWS credentials.
   - You may not have permission to deploy a serverless application. Make sure you
     provide all required permissions to deploy a serverless application.
 

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

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

doc/user/project/deploy_boards.md

@@ -90,7 +90,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/
    [`kubernetes`](https://docs.gitlab.com/runner/executors/kubernetes.html) executor.
 1. Configure the [Kubernetes integration](clusters/index.md) in your project for the
    cluster. The Kubernetes namespace is of particular note as you need it
-   for your deployment scripts (exposed by the `KUBE_NAMESPACE` environment variable).
+   for your deployment scripts (exposed by the `KUBE_NAMESPACE` deployment variable).
 1. Ensure Kubernetes annotations of `app.gitlab.com/env: $CI_ENVIRONMENT_SLUG`
    and `app.gitlab.com/app: $CI_PROJECT_PATH_SLUG` are applied to the
    deployments, replica sets, and pods, where `$CI_ENVIRONMENT_SLUG` and
@@ -163,6 +163,6 @@ version of your application.
 ## Further reading
 
 - [GitLab Auto deploy](../../topics/autodevops/stages.md#auto-deploy)
-- [GitLab CI/CD environment variables](../../ci/variables/README.md)
+- [GitLab CI/CD variables](../../ci/variables/README.md)
 - [Environments and deployments](../../ci/environments/index.md)
 - [Kubernetes deploy example](https://gitlab.com/gitlab-examples/kubernetes-deploy)

doc/user/project/deploy_tokens/index.md

@@ -169,7 +169,7 @@ apply consistently when cloning the repository of related projects.
 
 There's a special case when it comes to Deploy Tokens. If a user creates one
 named `gitlab-deploy-token`, the username and token of the Deploy Token is
-automatically exposed to the CI/CD jobs as environment variables: `CI_DEPLOY_USER`
+automatically exposed to the CI/CD jobs as CI/CD variables: `CI_DEPLOY_USER`
 and `CI_DEPLOY_PASSWORD`, respectively.
 
 After you create the token, you can sign in to the Container Registry by using

doc/user/project/push_options.md

@@ -34,12 +34,12 @@ git push -o <push_option>
 
 ## Push options for GitLab CI/CD
 
-You can use push options to skip a CI/CD pipeline, or pass environment variables.
+You can use push options to skip a CI/CD pipeline, or pass CI/CD variables.
 
 | Push option                    | Description                                                                                 | Introduced in version |
 | ------------------------------ | ------------------------------------------------------------------------------------------- |---------------------- |
 | `ci.skip`                      | Do not create a CI pipeline for the latest push.                                            | [11.7](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15643) |
-| `ci.variable="<name>=<value>"` | Provide [environment variables](../../ci/variables/README.md) to be used in a CI pipeline, if one is created due to the push. | [12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/27983) |
+| `ci.variable="<name>=<value>"` | Provide [CI/CD variables](../../ci/variables/README.md) to be used in a CI pipeline, if one is created due to the push. | [12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/27983) |
 
 An example of using `ci.skip`:
 
@@ -47,7 +47,7 @@ An example of using `ci.skip`:
 git push -o ci.skip
 ```
 
-An example of passing some environment variables for a pipeline:
+An example of passing some CI/CD variables for a pipeline:
 
 ```shell
 git push -o ci.variable="MAX_RETRIES=10" -o ci.variable="MAX_TIME=600"

doc/user/project/web_ide/index.md

@@ -421,7 +421,7 @@ terminal:
   See [this issue](https://gitlab.com/gitlab-org/webide-file-sync/-/issues/7) for
   more information.
 - `$CI_PROJECT_DIR` is a
-  [predefined environment variable](../../../ci/variables/predefined_variables.md)
+  [predefined CI/CD variable](../../../ci/variables/predefined_variables.md)
   for GitLab Runners. This is where your project's repository resides.
 
 After you have configured the web terminal for file syncing, then when the web