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

Change usage of CI/CD variables terminology in development docs

See merge request gitlab-org/gitlab!55144

doc/ci/examples/deployment/README.md

@@ -128,4 +128,4 @@ or `%` (for Windows Batch runners):
 1. `$VARIABLE` - use it for non-Windows runners
 1. `%VARIABLE%` - use it for Windows Batch runners
 
-Read more about the [CI variables](../../variables/README.md).
+Read more about the [CI/CD variables](../../variables/README.md).

doc/ci/variables/README.md

@@ -161,7 +161,7 @@ You can use tools like [the AWS CLI](https://docs.aws.amazon.com/cli/latest/user
 and [`kubectl`](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/#the-kubeconfig-environment-variable)
 to customize your configuration by using **File** type variables.
 
-Previously, a common pattern was to read the value of a CI variable, save it in a file, and then
+Previously, a common pattern was to read the value of a CI/CD variable, save it in a file, and then
 use that file in your script:
 
 ```shell

doc/ci/yaml/script.md

@@ -121,10 +121,10 @@ 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 CI/CD variables](../variables/README.md#custom-cicd-variables),
+You can define the color codes in Shell environment 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`:
+For example, using the same example as above and environment variables defined in a `before_script`:
 
 ```yaml
 job:

doc/development/build_test_package.md

@@ -40,7 +40,7 @@ used to trigger the build.
 
 In scenarios where a configuration change is to be introduced and Omnibus GitLab
 repository already has the necessary changes in a specific branch, you can build
-a package against that branch through an environment variable named
-`OMNIBUS_BRANCH`. To do this, specify that environment variable with the name of
+a package against that branch through a CI/CD variable named
+`OMNIBUS_BRANCH`. To do this, specify that variable with the name of
 the branch as value in `.gitlab-ci.yml` and push a commit. This will create a
 manual job that can be used to trigger the build.

doc/development/cicd/templates.md

@@ -47,7 +47,7 @@ performance:
 ```
 
 and users include this template with passing an argument to the `performance` job.
-This can be done by specifying the environment variable `TARGET_URL` in _their_ `.gitlab-ci.yml`:
+This can be done by specifying the CI/CD variable `TARGET_URL` in _their_ `.gitlab-ci.yml`:
 
 ```yaml
 include:
@@ -180,7 +180,7 @@ is updated in a major version GitLab release.
 ## Security
 
 A template could contain malicious code. For example, a template that contains the `export` shell command in a job
-might accidentally expose project secret variables in a job log.
+might accidentally expose secret project CI/CD variables in a job log.
 If you're unsure if it's secure or not, you need to ask security experts for cross-validation.
 
 ## Contribute CI/CD Template Merge Requests

doc/development/documentation/site_architecture/release_process.md

@@ -183,7 +183,7 @@ the [`compile_dev` job](https://gitlab.com/gitlab-org/gitlab-docs/-/jobs/3280424
 the `master` branches were pulled.
 
 To fix this, re-run the pipeline (`https://gitlab.com/gitlab-org/gitlab-docs/pipelines/new`)
-for the `update-12-2-for-release-12-4` branch, by including the following environment variables:
+for the `update-12-2-for-release-12-4` branch, by including the following CI/CD variables:
 
 - `BRANCH_CE` set to `12-2-stable`
 - `BRANCH_EE` set to `12-2-stable-ee`

doc/development/integrations/secure.md

@@ -89,7 +89,7 @@ it's declared under the `reports:sast` key in the job definition, not because of
 ### Policies
 
 Certain GitLab workflows, such as [AutoDevOps](../../topics/autodevops/customize.md#disable-jobs),
-define variables to indicate that given scans should be disabled. You can check for this by looking
+define CI/CD variables to indicate that given scans should be disabled. You can check for this by looking
 for variables such as `DEPENDENCY_SCANNING_DISABLED`, `CONTAINER_SCANNING_DISABLED`,
 `SAST_DISABLED`, and `DAST_DISABLED`. If appropriate based on the scanner type, you should then
 disable running the custom scanner.
@@ -97,7 +97,7 @@ disable running the custom scanner.
 GitLab also defines a `CI_PROJECT_REPOSITORY_LANGUAGES` variable, which provides the list of
 languages in the repository. Depending on this value, your scanner may or may not do something different.
 Language detection currently relies on the [`linguist`](https://github.com/github/linguist) Ruby gem.
-See [GitLab CI/CD predefined variables](../../ci/variables/predefined_variables.md).
+See the [predefined CI/CD variables](../../ci/variables/predefined_variables.md).
 
 #### Policy checking example
 
@@ -170,23 +170,23 @@ It also generates text output on the standard output and standard error streams,
 
 ### Variables
 
-All CI variables are passed to the scanner as environment variables.
-The scanned project is described by the [predefined CI variables](../../ci/variables/README.md).
+All CI/CD variables are passed to the scanner as environment variables.
+The scanned project is described by the [predefined CI/CD variables](../../ci/variables/README.md).
 
 #### SAST and Dependency Scanning
 
-SAST and Dependency Scanning scanners must scan the files in the project directory, given by the `CI_PROJECT_DIR` variable.
+SAST and Dependency Scanning scanners must scan the files in the project directory, given by the `CI_PROJECT_DIR` CI/CD variable.
 
 #### Container Scanning
 
 In order to be consistent with the official Container Scanning for GitLab,
 scanners must scan the Docker image whose name and tag are given by
 `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG`, respectively. If the `DOCKER_IMAGE`
-variable is provided, then the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` variables
+CI/CD variable is provided, then the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` variables
 are ignored, and the image specified in the `DOCKER_IMAGE` variable is scanned instead.
 
 If not provided, `CI_APPLICATION_REPOSITORY` should default to
-`$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`, which is a combination of predefined CI variables.
+`$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`, which is a combination of predefined CI/CD variables.
 `CI_APPLICATION_TAG` should default to `CI_COMMIT_SHA`.
 
 The scanner should sign in the Docker registry
@@ -197,13 +197,13 @@ If these are not defined, then the scanner should use
 #### Configuration files
 
 While scanners may use `CI_PROJECT_DIR` to load specific configuration files,
-it is recommended to expose configuration as environment variables, not files.
+it is recommended to expose configuration as CI/CD variables, not files.
 
 ### Output file
 
-Like any artifact uploaded to the GitLab CI/CD,
+Like any artifact uploaded to GitLab CI/CD,
 the Secure report generated by the scanner must be written in the project directory,
-given by the `CI_PROJECT_DIR` environment variable.
+given by the `CI_PROJECT_DIR` CI/CD variable.
 
 It is recommended to name the output file after the type of scanning, and to use `gl-` as a prefix.
 Since all Secure reports are JSON files, it is recommended to use `.json` as a file extension.
@@ -242,7 +242,7 @@ Also, we recommend prefixing error messages with `[ERRO]`, warnings with `[WARN]
 #### Logging level
 
 The scanner should filter out a log message if its log level is lower than the
-one set in the `SECURE_LOG_LEVEL` variable. For instance, `info` and `warn`
+one set in the `SECURE_LOG_LEVEL` CI/CD variable. For instance, `info` and `warn`
 messages should be skipped when `SECURE_LOG_LEVEL` is set to `error`. Accepted
 values are as follows, listed from highest to lowest:
 

doc/development/multi_version_compatibility.md

@@ -207,7 +207,7 @@ variable `CI_NODE_TOTAL` being an integer failed. This was caused because after
 1. Old code: Runners requested a job from an API node that is running the previous version.
 1. As a result, the [new code](https://gitlab.com/gitlab-org/gitlab/blob/42b82a9a3ac5a96f9152aad6cbc583c42b9fb082/app/models/concerns/ci/contextable.rb#L104)
 was not run on the API server. The runner's request failed because the
-older API server tried return the `CI_NODE_TOTAL` CI variable, but
+older API server tried return the `CI_NODE_TOTAL` CI/CD variable, but
 instead of sending an integer value (e.g. 9), it sent a serialized
 `Hash` value (`{:number=>9, :total=>9}`).
 

doc/development/pipelines.md

@@ -29,7 +29,7 @@ Pipelines are always created for the following scenarios:
 - Tags.
 - Stable, `auto-deploy`, and security branches.
 
-Pipeline creation is also affected by the following CI variables:
+Pipeline creation is also affected by the following CI/CD variables:
 
 - If `$FORCE_GITLAB_CI` is set, pipelines are created.
 - If `$GITLAB_INTERNAL` is not set, pipelines are not created.
@@ -414,10 +414,10 @@ The `rspec fail-fast` is a no-op if there are more than 10 test files related to
 Merge Request. This prevents `rspec fail-fast` duration from exceeding the average
 `rspec` job duration and defeating its purpose.
 
-This number can be overridden by setting a CI variable named `RSPEC_FAIL_FAST_TEST_FILE_COUNT_THRESHOLD`.
+This number can be overridden by setting a CI/CD variable named `RSPEC_FAIL_FAST_TEST_FILE_COUNT_THRESHOLD`.
 
 NOTE:
-This experiment is only enabled when the CI variable `RSPEC_FAIL_FAST_ENABLED=true` is set.
+This experiment is only enabled when the CI/CD variable `RSPEC_FAIL_FAST_ENABLED=true` is set.
 
 #### Determining related test files in a Merge Request
 
@@ -531,8 +531,7 @@ several reasons:
 The pre-clone step works by using the `CI_PRE_CLONE_SCRIPT` variable
 [defined by GitLab.com shared runners](../user/gitlab_com/index.md#pre-clone-script).
 
-The `CI_PRE_CLONE_SCRIPT` is currently defined as a project CI/CD
-variable:
+The `CI_PRE_CLONE_SCRIPT` is currently defined as a project CI/CD variable:
 
 ```shell
 echo "Downloading archived master..."
@@ -638,7 +637,7 @@ Some of the jobs are using images from Docker Hub, where we also use
 `${GITLAB_DEPENDENCY_PROXY}` as a prefix to the image path, so that we pull
 images from our [Dependency Proxy](../user/packages/dependency_proxy/index.md).
 
-`${GITLAB_DEPENDENCY_PROXY}` is a group variable defined in
+`${GITLAB_DEPENDENCY_PROXY}` is a group CI/CD variable defined in
 [`gitlab-org`](https://gitlab.com/gitlab-org) as
 `${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/`. This means when we use an image
 defined as:
@@ -653,7 +652,7 @@ Docker Hub unless `${GITLAB_DEPENDENCY_PROXY}` is also defined there.
 
 ### Default variables
 
-In addition to the [predefined variables](../ci/variables/predefined_variables.md),
+In addition to the [predefined CI/CD variables](../ci/variables/predefined_variables.md),
 each pipeline includes default variables defined in
 [`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
 
@@ -679,7 +678,7 @@ that are scoped to a single [configuration keyword](../ci/yaml/README.md#job-key
 | `.use-pg12` | Allows a job to use the `postgres:12` and `redis:4.0-alpine` services. |
 | `.use-pg12-ee` | Same as `.use-pg12` but also use the `docker.elastic.co/elasticsearch/elasticsearch:7.9.2` services. |
 | `.use-kaniko` | Allows a job to use the `kaniko` tool to build Docker images. |
-| `.as-if-foss` | Simulate the FOSS project by setting the `FOSS_ONLY='1'` environment variable. |
+| `.as-if-foss` | Simulate the FOSS project by setting the `FOSS_ONLY='1'` CI/CD variable. |
 | `.use-docker-in-docker` | Allows a job to use Docker in Docker. |
 
 ### `rules`, `if:` conditions and `changes:` patterns
@@ -726,7 +725,7 @@ and included in `rules` definitions via [YAML anchors](../ci/yaml/README.md#anch
 | `if-dot-com-gitlab-org-and-security-tag`                     | Limit jobs creation to tags for the `gitlab-org` and `gitlab-org/security` groups on GitLab.com. | |
 | `if-dot-com-ee-schedule`                                     | Limits jobs to scheduled pipelines for the `gitlab-org/gitlab` project on GitLab.com. | |
 | `if-cache-credentials-schedule`                              | Limits jobs to scheduled pipelines with the `$CI_REPO_CACHE_CREDENTIALS` variable set. | |
-| `if-rspec-fail-fast-disabled`                                | Limits jobs to pipelines with `$RSPEC_FAIL_FAST_ENABLED` variable not set to `"true"`. | |
+| `if-rspec-fail-fast-disabled`                                | Limits jobs to pipelines with `$RSPEC_FAIL_FAST_ENABLED` CI/CD variable not set to `"true"`. | |
 | `if-rspec-fail-fast-skipped`                                 | Matches if the pipeline is for a merge request and the MR title includes "SKIP RSPEC FAIL-FAST". | |
 | `if-security-pipeline-merge-result`                          | Matches if the pipeline is for a security merge request triggered by `@gitlab-release-tools-bot`. | |
 

doc/development/testing_guide/end_to_end/environment_selection.md

@@ -58,7 +58,7 @@ end
 If the test has a `before` or `after`, you must add the `only` metadata
 to the outer `RSpec.describe`.
 
-If you want to run an `only: { :pipeline }` tagged test on your local GDK make sure either the `CI_PROJECT_NAME` environment variable is unset, or that the `CI_PROJECT_NAME` environment variable matches the specified pipeline in the `only: { :pipeline }` tag, or just delete the `only: { :pipeline }` tag.
+If you want to run an `only: { :pipeline }` tagged test on your local GDK make sure either the `CI_PROJECT_NAME` CI/CD variable is unset, or that the `CI_PROJECT_NAME` variable matches the specified pipeline in the `only: { :pipeline }` tag, or just delete the `only: { :pipeline }` tag.
 
 ## Quarantining a test for a specific environment
 

doc/operations/metrics/dashboards/variables.md

@@ -16,7 +16,7 @@ Queries that continue to use the old format display no data.
 
 ## Predefined variables
 
-GitLab supports a limited set of [CI variables](../../../ci/variables/README.md)
+GitLab supports a limited set of [CI/CD variables](../../../ci/variables/README.md)
 in the Prometheus query. This is particularly useful for identifying a specific
 environment, for example with `ci_environment_slug`. Variables for Prometheus queries
 must be lowercase. The supported variables are:

doc/topics/autodevops/troubleshooting.md

@@ -92,7 +92,7 @@ If you receive this error, you can do one of the following actions:
   `POSTGRES_ENABLED` to `false` and re-deploy. This option is especially relevant to
   users of *custom charts without the in-chart PostgreSQL dependency*.
   Database auto-detection is based on the `postgresql.enabled` Helm value for
-  your release. This value is set based on the `POSTGRES_ENABLED` CI variable
+  your release. This value is set based on the `POSTGRES_ENABLED` CI/CD variable
   and persisted by Helm, regardless of whether or not your chart uses the
   variable.
 

doc/user/project/deploy_boards.md

@@ -94,7 +94,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/
 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
-   `$CI_PROJECT_PATH_SLUG` are the values of the CI variables. This is so we can
+   `$CI_PROJECT_PATH_SLUG` are the values of the CI/CD variables. This is so we can
    lookup the proper environment in a cluster/namespace which may have more
    than one. These resources should be contained in the namespace defined in
    the Kubernetes service setting. You can use an [Auto deploy](../../topics/autodevops/stages.md#auto-deploy) `.gitlab-ci.yml`

doc/user/project/requirements/index.md

@@ -183,7 +183,7 @@ requirements_confirmation:
 ### Add the manual job to CI conditionally
 
 To configure your CI to include the manual job only when there are some open
-requirements, add a rule which checks `CI_HAS_OPEN_REQUIREMENTS` CI variable.
+requirements, add a rule which checks `CI_HAS_OPEN_REQUIREMENTS` CI/CD variable.
 
 ```yaml
 requirements_confirmation:

doc/user/project/settings/import_export.md

@@ -124,7 +124,7 @@ The following items will **not** be exported:
 
 - Build traces and artifacts
 - Container registry images
-- CI variables
+- CI/CD variables
 - Webhooks
 - Any encrypted tokens
 - Merge Request Approvers