Commit fa01f9f0 authored by Marcel Amirault's avatar Marcel Amirault Committed by Mike Jang

Update environment variable terminology

Make sure environment variables are referred to as
CI/CD variables or environment variables, as needed
parent b5e740a0
......@@ -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).
......@@ -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
......
......@@ -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:
......
......@@ -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.
......@@ -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
......
......@@ -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`
......
......@@ -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:
......
......@@ -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}`).
......
......@@ -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`. | |
......
......@@ -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
......
......@@ -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:
......
......@@ -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.
......
......@@ -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`
......
......@@ -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:
......
......@@ -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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment