GitLab CI/CD environment variables

An environment variable is a dynamically-named value that can affect the way running processes behave on an operating system.

Environment variables are part of the environment in which a process runs. For example, a running process can query the value of the TEMP environment variable to discover a suitable location to store temporary files, or to define a URL for a database that can be reused in different scripts.

Variables are useful for customizing your jobs in GitLab CI/CD. When you use variables, you don't have to hard-code values.

Predefined environment variables

GitLab CI/CD has a default set of predefined variables that you can use without any additional specification. You can call issue numbers, user names, branch names, pipeline and commit IDs, and much more.

Predefined environment variables are provided by GitLab for the local environment of the Runner.

GitLab reads the .gitlab-ci.yml file and sends the information to the Runner, where the variables are exposed. The Runner then runs the script commands.

Use predefined environment variables

You can choose one of the existing predefined variables to be output by the Runner.

This example shows how to output a job's stage by using the predefined variable CI_JOB_STAGE.

In your .gitlab-ci.yml file, call the variable from your script. Ensure you use the correct syntax.

test_variable:
  stage: test
  script:
    - echo $CI_JOB_STAGE

In this case, the Runner outputs the stage for the job test_variable, which is test:

As another example, let's say you're using your own GitLab instance and you want to know what domain your GitLab Pages are served under. You can call it by using the predefined variable $CI_PAGES_DOMAIN in your script:

pages:
  script:
    - ...
    - echo $CI_PAGES_DOMAIN

For GitLab.com users, the output will be gitlab.io. For your private instance, the output will be whatever your sysadmin has defined.

Custom environment variables

When you need a specific custom environment variable, you can set it up in the UI, in the API, or directly in the .gitlab-ci.yml file.

The variables are used by the Runner any time the pipeline runs. You can also override variable values manually for a specific pipeline.

There are two types of variables: Variable and File. You cannot set types in the .gitlab-ci.yml file, but you can set them in the UI and API.

Create a custom variable in `.gitlab-ci.yml`

To create a custom env_var variable in the .gitlab-ci.yml file, define the variable/value pair under variables:

variables:
  TEST: "HELLO WORLD"

You can then call its value in your script:

  script:
    - echo "$TEST"

For more details, see .gitlab-ci.yml defined variables.

Create a custom variable in the UI

From within the UI, you can add or update custom environment variables:

Go to your project's Settings > CI/CD and expand the Variables section.
Click the Add Variable button. In the Add variable modal, fill in the details:
- Key: Must be one line, with no spaces, using only letters, numbers, - or _.
- Value: No limitations.
- Type: File or Variable.
- Environment scope: All, or specific environments.
- Protect variable (Optional): If selected, the variable will only be available in pipelines that run on protected branches or tags.
- Mask variable (Optional): If selected, the variable's Value will be masked in job logs. The variable fails to save if the value does not meet the masking requirements.

After a variable is created, you can update any of the details by clicking the {pencil} Edit button.

After you set a variable, call it from 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 will be:

Custom environment variables of type Variable

Introduced in GitLab 11.11.

For variables with the type Variable, the Runner creates an environment variable that uses the key for the name and the value for the value.

There are some predefined variables of this type, which may be further validated. They appear when you add or update a variable in the UI.

Custom environment variables of type File

Introduced in GitLab 11.11.

For variables with the type File, the Runner creates an environment variable that uses the key for the name. For the value, the Runner writes the variable value to a temporary file and uses this path.

You can use tools like the AWS CLI and kubectl to customize your configuration by using File type variables.

In the past, a common pattern was to read the value of a CI variable, save it in a file, and then use the newly created 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"

Instead of this, you can use a File type variable. For example, if you have the following variables:

A variable of type Variable: KUBE_URL with the value https://example.com.
A variable of type File: KUBE_CA_PEM with a certificate as the value.

You can call them from .gitlab-ci.yml, like this:

kubectl config set-cluster e2e --server="$KUBE_URL" --certificate-authority="$KUBE_CA_PEM"

Mask a custom variable

Introduced in GitLab 11.10

Variables can be masked so that the value of the variable will be hidden in job logs.

To mask a variable:

Go to Settings > CI/CD.
Expand the Variables section.
Next to the variable you want to protect, click Edit.
Select the Mask variable check box.
Click Update variable.

Masked variable requirements

The value of the variable must:

Be in a single line.
Be at least 8 characters long.
Not be a predefined or custom environment variable.
Consist only of characters from the Base64 alphabet (RFC4648). In GitLab 12.2 and newer, @ and : are also valid values.

You can't mask variables that don't meet these requirements.

Protect a custom variable

Introduced in GitLab 9.3.

Variables can be protected. When a variable is protected, it is securely passed to pipelines running on protected branches or protected tags only. The other pipelines do not get the protected variable.

To protect a variable:

Go to Settings > CI/CD.
Expand the Variables section.
Next to the variable you want to protect, click Edit.
Select the Protect variable check box.
Click Update variable.

The variable is available for all subsequent pipelines.

Custom variables validated by GitLab

Some variables are listed in the UI so you can choose them more quickly. GitLab validates the values of these variables to ensure they are in the correct format.

Variable	Allowed Values	Introduced in
`AWS_ACCESS_KEY_ID`	20 characters: letters, digits	12.10
`AWS_DEFAULT_REGION`	Any	12.10
`AWS_SECRET_ACCESS_KEY`	40 characters: letters, digits, special characters	12.10

NOTE: Note: When you store credentials, there are security implications. If you are using AWS keys, for example, follow their best practices.

Syntax of environment variables in job scripts

All variables are set as environment variables in the build environment, and they are accessible with normal methods that are used to access such variables. In most cases bash or sh is used to execute the job script.

To access environment variables, use the syntax for your Runner's shell.

Shell	Usage
bash/sh	`$variable`
windows batch	`%variable%`
PowerShell	`$env:variable`

To access environment variables in bash, prefix the variable name with ($):

job_name:
  script:
    - echo $CI_JOB_ID

To access environment variables in Windows Batch, surround the variable with (%):

job_name:
  script:
    - echo %CI_JOB_ID%

To access environment variables in a Windows PowerShell environment, prefix the variable name with ($env:):

job_name:
  script:
    - echo $env:CI_JOB_ID

You can also list all environment variables with the export command, but be aware that this will also expose the values of all the variables you set, in the job log:

job_name:
  script:
    - export

Example values:

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:abcde-1234ABCD5678ef@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="abcde-1234ABCD5678ef"
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_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="longalfanumstring"
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"

`.gitlab-ci.yml` defined variables

NOTE: Note: This feature requires GitLab Runner 0.5.0 or higher and GitLab 7.14 or higher.

You can add variables that are set in the build environment to .gitlab-ci.yml. These variables are saved in the repository, and they are meant to store non-sensitive project configuration, like RAILS_ENV or DATABASE_URL.

For example, if you set the variable below globally (not inside a job), it will be used in all executed commands and scripts:

variables:
  DATABASE_URL: "postgres://postgres@postgres/my_database"

The YAML-defined variables are also set to all created service containers, so that you can fine tune them.

Variables can be defined at a global level, but also at a job level. To turn off global defined variables in your job, define an empty hash:

job_name:
  variables: {}

You are able to use other variables inside your variable definition (or escape them with $$):

variables:
  LS_CMD: 'ls $FLAGS $$TMP_DIR'
  FLAGS: '-al'
script:
  - 'eval $LS_CMD'  # will execute 'ls -al $TMP_DIR'

Group-level environment variables

Introduced in GitLab 9.4.

You can define per-project or per-group variables that are set in the pipeline environment. Group-level variables are stored out of the repository (not in .gitlab-ci.yml) and are securely passed to GitLab Runner making them available during a pipeline run. It's the recommended method to use for storing things like passwords, SSH keys, and credentials.

Group-level variables can be added by:

Navigating to your group's Settings > CI/CD page.
Inputting variable types, keys, and values in the Variables section. Any variables of subgroups will be inherited recursively.

Once you set them, they will be available for all subsequent pipelines. Any group-level user defined variables can be viewed in projects by:

Navigating to the project's Settings > CI/CD page.
Expanding the Variables section.

Inherit environment variables

Introduced in GitLab 13.0.

It's deployed behind a feature flag (ci_dependency_variables), disabled by default.

You can inherit environment 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

Enable inherited environment variables (CORE ONLY)

The Inherited Environment Variables feature is under development and not ready for production use. It is deployed behind a feature flag that is disabled by default. GitLab administrators with access to the GitLab Rails console can enable it for your instance.

To enable it:

Feature.enable(:ci_dependency_variables)

To disable it:

Feature.disable(:ci_dependency_variables)

Priority of environment 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 or scheduled pipeline variables.
Project-level variables or protected variables.
Group-level variables or protected variables.
Inherited environment variables.
YAML-defined job-level variables.
YAML-defined global variables.
Deployment variables.
Predefined environment variables.

For example, if you define:

API_TOKEN=secure as a project variable.
API_TOKEN=yaml in your .gitlab-ci.yml.

API_TOKEN will take the value secure as the project variables take precedence over those defined in .gitlab-ci.yml.

Unsupported variables

There are cases where some variables cannot be used in the context of a .gitlab-ci.yml definition (for example under script). Read more about which variables are not supported.

Where variables can be used

Click here for a section that describes where and how the different types of variables can be used.

Advanced use

Limit the environment scopes of environment 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 environment variables

Introduced in GitLab 8.15.

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 variables to the running application by prefixing the key of the variable with K8S_SECRET_.

These prefixed variables will then be available as environment variables on the running application container.

CAUTION: Caution: Variables with multiline values are not currently supported due to limitations with the current Auto DevOps scripting environment.

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.

Navigate to your project's CI/CD > Pipelines and click 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.

Environment variables expressions

Introduced in GitLab 10.7 for the only and except CI keywords

Expanded in GitLab 12.3 with the rules keyword

Use variable expressions to limit which jobs are created within a pipeline after changes are pushed to GitLab.

In .gitlab-ci.yml, variable expressions work with both:

rules, which is the recommended approach, and
only and except, 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 environment 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 is going to evaluate to truth if variable is not defined when == is used, or to falsey if != is used.
Checking for an empty variable

Examples:
- $VARIABLE == ""
- $VARIABLE != "" (introduced in GitLab 11.11)
If you want to check whether a variable is defined, but is empty, you can simply compare it against an empty string, like $VAR == '' or 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 is going to compare values of these variables.
Variable presence check

Example: $STAGING

If you only want to create a job when there is some variable present, which means that it is defined and non-empty, you can simply use variable name as an expression, like $STAGING. If $STAGING variable is defined, and is non empty, expression will evaluate to truth. $STAGING value needs to a string, with length higher than zero. Variable that contains only whitespace characters is not an empty variable.
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 ||.

Storing regular expressions in variables

It is possible to store a regular expression in a variable, to be used for pattern matching:

variables:
  STAGINGRELS: '/staging0|staging1/'

deploy_staging:
  script: do.sh deploy staging
  environment: staging
  rules:
    - if: '$RELEASE =~ $STAGINGRELS'

NOTE: 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 will work in a variable. The example below tests the ^mast.* regular expression directly, as well as from within 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.

CAUTION: 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, GitLab 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, resulting 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.

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_BUILD_ID=379424655
++ CI_BUILD_ID=379424655
++ export CI_BUILD_TOKEN=[MASKED]
++ CI_BUILD_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_BUILD_NAME=debug_trace
++ CI_BUILD_NAME=debug_trace
++ export CI_BUILD_STAGE=test
++ CI_BUILD_STAGE=test
++ 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 CI_SERVER_VERSION=12.6.0-pre
++ CI_SERVER_VERSION=12.6.0-pre
++ export CI_SERVER_VERSION_MAJOR=12
++ CI_SERVER_VERSION_MAJOR=12
++ export CI_SERVER_VERSION_MINOR=6
++ CI_SERVER_VERSION_MINOR=6
++ export CI_SERVER_VERSION_PATCH=0
++ CI_SERVER_VERSION_PATCH=0
++ export CI_SERVER_REVISION=f4cc00ae823
++ CI_SERVER_REVISION=f4cc00ae823
++ 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_clusters,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
++ 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_clusters,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_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
++ export CI_COMMIT_MESSAGE=s/CI/Runner
++ CI_COMMIT_MESSAGE=s/CI/Runner
++ export CI_COMMIT_TITLE=s/CI/Runner
++ CI_COMMIT_TITLE=s/CI/Runner
++ export CI_COMMIT_DESCRIPTION=
++ CI_COMMIT_DESCRIPTION=
++ export CI_COMMIT_REF_PROTECTED=true
++ CI_COMMIT_REF_PROTECTED=true
++ export CI_BUILD_REF=dd648b2e48ce6518303b0bb580b2ee32fadaf045
++ CI_BUILD_REF=dd648b2e48ce6518303b0bb580b2ee32fadaf045
++ export CI_BUILD_BEFORE_SHA=0000000000000000000000000000000000000000
++ CI_BUILD_BEFORE_SHA=0000000000000000000000000000000000000000
++ export CI_BUILD_REF_NAME=master
++ CI_BUILD_REF_NAME=master
++ export CI_BUILD_REF_SLUG=master
++ CI_BUILD_REF_SLUG=master
++ export CI_RUNNER_ID=1337
++ CI_RUNNER_ID=1337
++ export CI_RUNNER_DESCRIPTION=shared-runners-manager-4.gitlab.com
++ CI_RUNNER_DESCRIPTION=shared-runners-manager-4.gitlab.com
++ export 'CI_RUNNER_TAGS=gce, east-c, shared, docker, linux, ruby, mysql, postgres, mongo, git-annex'
++ CI_RUNNER_TAGS='gce, east-c, shared, docker, linux, ruby, mysql, postgres, mongo, git-annex'
++ export CI_DEBUG_TRACE=true
++ CI_DEBUG_TRACE=true
++ export GITLAB_USER_ID=42
++ GITLAB_USER_ID=42
++ export GITLAB_USER_EMAIL=user@example.com
++ GITLAB_USER_EMAIL=user@example.com
++ export GITLAB_USER_LOGIN=root
++ GITLAB_USER_LOGIN=root
++ export 'GITLAB_USER_NAME=User'
++ GITLAB_USER_NAME='User'
++ export CI_DISPOSABLE_ENVIRONMENT=true
++ CI_DISPOSABLE_ENVIRONMENT=true
++ export CI_RUNNER_VERSION=12.5.0
++ CI_RUNNER_VERSION=12.5.0
++ export CI_RUNNER_REVISION=577f813d
++ CI_RUNNER_REVISION=577f813d
++ export CI_RUNNER_EXECUTABLE_ARCH=linux/amd64
++ CI_RUNNER_EXECUTABLE_ARCH=linux/amd64
++ export VERY_SECURE_VARIABLE=imaverysecurevariable
++ VERY_SECURE_VARIABLE=imaverysecurevariable

...

Video walkthrough of a working example

The Managing the Complex Configuration Data Management Monster Using GitLab video is a walkthrough of the Complex Config 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.