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/topics/autodevops/quick_start_guide.md

@@ -234,8 +234,8 @@ takes you to the pod's logs page.
 
 NOTE:
 The example shows only one pod hosting the application at the moment, but you can add
-more pods by defining the [`REPLICAS` variable](customize.md#environment-variables)
-in **Settings > CI/CD > Environment variables**.
+more pods by defining the [`REPLICAS` CI/CD variable](customize.md#cicd-variables)
+in **Settings > CI / CD > Variables**.
 
 ### Work with branches
 
@@ -307,7 +307,7 @@ and customized to fit your workflow. Here are some helpful resources for further
 1. [Auto DevOps](index.md)
 1. [Multiple Kubernetes clusters](index.md#using-multiple-kubernetes-clusters)
 1. [Incremental rollout to production](customize.md#incremental-rollout-to-production) **(PREMIUM)**
-1. [Disable jobs you don't need with environment variables](customize.md#environment-variables)
+1. [Disable jobs you don't need with CI/CD variables](customize.md#cicd-variables)
 1. [Use a static IP for your cluster](../../user/clusters/applications.md#using-a-static-ip)
 1. [Use your own buildpacks to build your application](customize.md#custom-buildpacks)
 1. [Prometheus monitoring](../../user/project/integrations/prometheus.md)

doc/topics/autodevops/requirements.md

@@ -109,8 +109,8 @@ After all requirements are met, you can [enable Auto DevOps](index.md#enablingdi
 
 You can choose to target [AWS ECS](../../ci/cloud_deployment/index.md) as a deployment platform instead of using Kubernetes.
 
-To get started on Auto DevOps to AWS ECS, you must add a specific Environment
-Variable. To do so, follow these steps:
+To get started on Auto DevOps to AWS ECS, you must add a specific CI/CD variable.
+To do so, follow these steps:
 
 1. In your project, go to **Settings > CI / CD** and expand the **Variables**
    section.
@@ -121,7 +121,7 @@ Variable. To do so, follow these steps:
    - `ECS` if you're not enforcing any launch type check when deploying to ECS.
 
 When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly
-[entered AWS credentials as environment variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
+[entered AWS credentials as variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
 your application is deployed to AWS ECS.
 
 [GitLab Managed Apps](../../user/clusters/applications.md) are not available when deploying to AWS ECS.
@@ -145,7 +145,7 @@ own pipeline, as the override stops working when the name changes.
 
 You can target [AWS EC2](../../ci/cloud_deployment/index.md)
 as a deployment platform instead of Kubernetes. To use Auto DevOps with AWS EC2, you must add a
-specific environment variable.
+specific CI/CD variable.
 
 For more details, see [Custom build job for Auto DevOps](../../ci/cloud_deployment/index.md#custom-build-job-for-auto-devops)
 for deployments to AWS EC2.

doc/topics/autodevops/stages.md

@@ -53,7 +53,7 @@ For the requirements of other languages and frameworks, read the
 
 NOTE:
 If Auto Build fails despite the project meeting the buildpack requirements, set
-a project variable `TRACE=true` to enable verbose logging, which may help you
+a project CI/CD variable `TRACE=true` to enable verbose logging, which may help you
 troubleshoot.
 
 ### Auto Build using Cloud Native Buildpacks (beta)
@@ -62,9 +62,9 @@ troubleshoot.
 
 Auto Build supports building your application using [Cloud Native Buildpacks](https://buildpacks.io)
 through the [`pack` command](https://github.com/buildpacks/pack). To use Cloud Native Buildpacks,
-set the CI variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` to a non-empty
+set the CI/CD variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` to a non-empty
 value. The default builder is `heroku/buildpacks:18` but a different builder
-can be selected using the CI variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.
+can be selected using the CI/CD variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.
 
 Cloud Native Buildpacks (CNBs) are an evolution of Heroku buildpacks, and
 GitLab expects them to eventually supersede Herokuish-based builds within Auto DevOps. For more
@@ -286,7 +286,7 @@ see the documentation.
 ### Overriding the DAST target
 
 To use a custom target instead of the auto-deployed review apps,
-set a `DAST_WEBSITE` environment variable to the URL for DAST to scan.
+set a `DAST_WEBSITE` CI/CD variable to the URL for DAST to scan.
 
 WARNING:
 If [DAST Full Scan](../../user/application_security/dast/index.md#full-scan) is
@@ -299,10 +299,10 @@ data loss or corruption.
 
 You can disable DAST:
 
-- On all branches by setting the `DAST_DISABLED` environment variable to `"true"`.
+- On all branches by setting the `DAST_DISABLED` CI/CD variable to `"true"`.
 - Only on the default branch by setting the `DAST_DISABLED_FOR_DEFAULT_BRANCH`
-  environment variable to `"true"`.
-- Only on feature branches by setting `REVIEW_DISABLED` environment variable to
+  variable to `"true"`.
+- Only on feature branches by setting `REVIEW_DISABLED` variable to
   `"true"`. This also disables the Review App.
 
 ## Auto Browser Performance Testing **(PREMIUM)**
@@ -338,7 +338,7 @@ uploads the report as an artifact.
 
 Some initial setup is required. A [k6](https://k6.io/) test needs to be
 written that's tailored to your specific application. The test also needs to be
-configured so it can pick up the environment's dynamic URL via an environment variable.
+configured so it can pick up the environment's dynamic URL via a CI/CD variable.
 
 Any load performance test result differences between the source and target branches are also
 [shown in the merge request widget](../../user/project/merge_requests/load_performance_testing.md).
@@ -358,7 +358,7 @@ default, but the
 [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
 contains job definitions for these tasks if you want to enable them.
 
-You can use [environment variables](customize.md#environment-variables) to automatically
+You can use [CI/CD variables](customize.md#cicd-variables) to automatically
 scale your pod replicas, and to apply custom arguments to the Auto DevOps `helm upgrade`
 commands. This is an easy way to
 [customize the Auto Deploy Helm chart](customize.md#custom-helm-chart).
@@ -442,7 +442,7 @@ On GitLab 12.9 and 12.10, opting into
 `AUTO_DEVOPS_POSTGRES_CHANNEL` version `2` deletes the version `1` PostgreSQL
 database. Follow the [guide to upgrading PostgreSQL](upgrading_postgresql.md)
 to back up and restore your database before opting into version `2` (On
-GitLab 13.0, an additional variable is required to trigger the database
+GitLab 13.0, an additional CI/CD variable is required to trigger the database
 deletion).
 
 ### Migrations
@@ -450,7 +450,7 @@ deletion).
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21955) in GitLab 11.4
 
 You can configure database initialization and migrations for PostgreSQL to run
-within the application pod by setting the project variables `DB_INITIALIZE` and
+within the application pod by setting the project CI/CD variables `DB_INITIALIZE` and
 `DB_MIGRATE` respectively.
 
 If present, `DB_INITIALIZE` is run as a shell command within an application pod
@@ -502,7 +502,7 @@ access to a Redis instance. Auto DevOps doesn't deploy this instance for you, so
 you must:
 
 - Maintain your own Redis instance.
-- Set a CI variable `K8S_SECRET_REDIS_URL`, which is the URL of this instance,
+- Set a CI/CD variable `K8S_SECRET_REDIS_URL`, which is the URL of this instance,
   to ensure it's passed into your deployments.
 
 After configuring your worker to respond to health checks, run a Sidekiq
@@ -688,5 +688,5 @@ You can follow the [code intelligence epic](https://gitlab.com/groups/gitlab-org
 for updates.
 
 This stage is enabled by default. You can disable it by adding the
-`CODE_INTELLIGENCE_DISABLED` environment variable. Read more about
+`CODE_INTELLIGENCE_DISABLED` CI/CD variable. Read more about
 [disabling Auto DevOps jobs](../../topics/autodevops/customize.md#disable-jobs).

doc/topics/autodevops/upgrading_auto_deploy_dependencies.md

@@ -114,7 +114,7 @@ If your Auto DevOps project has an active environment that was deployed with the
    job saves a backup for 1 week in a job artifact called `helm-2-release-backups`.
    The backup is in a Kubernetes manifest file that can be restored using
    `kubectl apply -f $backup`.
-1. Remove the `MIGRATE_HELM_2TO3` variable.
+1. Remove the `MIGRATE_HELM_2TO3` CI/CD variable.
 
 #### In-Cluster PostgreSQL Channel 2
 
@@ -145,11 +145,11 @@ steps to upgrade to v2:
    them to `production` first to delete the unstable tracks.
 1. Verify your project is [using the v2 `auto-deploy-image`](#verify-dependency-versions).
    If not, [specify the version](#use-a-specific-version-of-auto-deploy-dependencies).
-1. Add an `AUTO_DEVOPS_FORCE_DEPLOY_V2` environment variable with a value of `true`
+1. Add an `AUTO_DEVOPS_FORCE_DEPLOY_V2` CI/CD variable with a value of `true`
    in the GitLab CI/CD settings.
 1. Create a new pipeline and run the `production` job to renew the resource architecture
    with the v2 `auto-deploy-app chart`.
-1. Remove the `AUTO_DEVOPS_FORCE_DEPLOY_V2` environment variable.
+1. Remove the `AUTO_DEVOPS_FORCE_DEPLOY_V2` variable.
 
 ### Use a specific version of Auto Deploy dependencies
 
@@ -167,7 +167,7 @@ include:
 ### Ignore warnings and continue deploying
 
 If you are certain that the new chart version is safe to be deployed, you can add
-the `AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number>` [environment variable](customize.md#build-and-deployment)
+the `AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number>` [CI/CD variable](customize.md#build-and-deployment)
 to force the deployment to continue.
 
 For example, if you want to deploy the `v2.0.0` chart on a deployment that previously

doc/user/application_security/security_dashboard/index.md

@@ -175,7 +175,7 @@ lock files. Python projects can have lock files, but GitLab Secure tools don't s
 ## Security scans using Auto DevOps
 
 When using [Auto DevOps](../../../topics/autodevops/index.md), use
-[special environment variables](../../../topics/autodevops/customize.md#environment-variables)
+[special environment variables](../../../topics/autodevops/customize.md#cicd-variables)
 to configure daily security scans.
 
 <!-- ## Troubleshooting

doc/user/clusters/applications.md

@@ -372,7 +372,7 @@ For GitLab Runner to function, you _must_ specify the following:
 - `runnerRegistrationToken`: The registration token for adding new runners to GitLab.
   This must be [retrieved from your GitLab instance](../../ci/runners/README.md).
 
-These values can be specified using [CI variables](../../ci/variables/README.md):
+These values can be specified using [CI/CD variables](../../ci/variables/README.md):
 
 - `GITLAB_RUNNER_GITLAB_URL` is used for `gitlabUrl`.
 - `GITLAB_RUNNER_REGISTRATION_TOKEN` is used for `runnerRegistrationToken`
@@ -730,7 +730,7 @@ Set:
 - "Redirect URI" to `http://<JupyterHub Host>/hub/oauth_callback`.
 - "Scope" to `api read_repository write_repository`.
 
-In addition, the following variables must be specified using [CI variables](../../ci/variables/README.md):
+In addition, the following variables must be specified using [CI/CD variables](../../ci/variables/README.md):
 
 - `JUPYTERHUB_PROXY_SECRET_TOKEN` - Secure string used for signing communications
   from the hub. Read [`proxy.secretToken`](https://zero-to-jupyterhub.readthedocs.io/en/stable/reference/reference.html#proxy-secrettoken).

doc/user/project/clusters/add_eks_clusters.md

@@ -326,7 +326,7 @@ If a default Storage Class doesn't already exist and is desired, follow Amazon's
 to create one.
 
 Alternatively, disable PostgreSQL by setting the project variable
-[`POSTGRES_ENABLED`](../../../topics/autodevops/customize.md#environment-variables) to `false`.
+[`POSTGRES_ENABLED`](../../../topics/autodevops/customize.md#cicd-variables) to `false`.
 
 ### Deploy the app to EKS