On this page

Skip to content

GitLab CI Syntax and Variables Guide

I have recently started researching GitLab CI again. Although this work has been ongoing for a while, the intermittent nature of my study often leads me to look up the purpose of certain syntax repeatedly. I decided to have Claude help me organize some common syntax for easy reference in the future.

Basic Structure

The GitLab CI configuration file is .gitlab-ci.yml, which defines the tasks your project should execute in the GitLab CI pipeline.

General file naming conventions:

  • Main CI/CD configuration file: .gitlab-ci.yml (fixed name).
  • Included files (includes): Usually follow the .gitlab-ci-*.yml format, for example:
    • .gitlab-ci-deploy.yml
    • .gitlab-ci-build.yml
    • .gitlab-ci-test.yml

Stages

Stages define the order in which jobs are executed:

yaml
stages:
  - build
  - test
  - deploy

All jobs within a stage run in parallel, and all must succeed before moving to the next stage.

Common stage names (in order of execution):

  • build - Build phase.
  • test - Testing phase.
  • quality - Code quality checks.
  • security - Security checks.
  • publish - Publish to registry.
  • deploy - Deploy to environment.
  • notify - Notifications.
  • cleanup - Resource cleanup.

Jobs

Jobs are the units that actually perform the work:

yaml
build-job:
  stage: build
  script:
    - echo "Building the app..."
    - mkdir build
    - cd build
    - cmake ..

Naming conventions: Jobs usually follow the "action-object-environment" pattern, for example:

  • build-app
  • test-api
  • deploy-staging

Rules

Rules define the conditions under which a job is executed:

yaml
test-job:
  stage: test
  script:
    - echo "Running tests..."
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"
      when: always
    - when: never

Rules are evaluated in order. When a rule matches, the when value of that rule is applied to determine whether the job runs.

Only/Except

This is older syntax but still valid; it restricts job execution based on branches or tags:

yaml
deploy-job:
  stage: deploy
  script:
    - echo "Deploying application..."
  only:
    - main
    - tags

TIP

GitLab officially recommends using rules instead of only/except because rules provides more flexibility and control. The equivalent rules implementation is as follows:

yaml
deploy-job:
  stage: deploy
  script:
    - echo "Deploying application..."
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: always
    - if: $CI_COMMIT_TAG
      when: always
    - when: never

Variables

You can define global or job-specific variables:

yaml
variables:
  GLOBAL_VAR: "global value"

test-job:
  variables:
    JOB_SPECIFIC_VAR: "job specific value"
  script:
    - echo $GLOBAL_VAR
    - echo $JOB_SPECIFIC_VAR

Naming conventions: Variables are typically uppercase with underscores, for example:

  • APP_VERSION
  • DOCKER_IMAGE_NAME
  • DATABASE_URL

TIP

When using variables in GitLab CI, you can use the $VARIABLE_NAME or ${VARIABLE_NAME} syntax. When a variable name needs to be concatenated with other text, use the brace syntax ${VARIABLE_NAME} to clearly define the scope of the variable name and avoid parsing errors.

Before Script / After Script

Scripts to be executed before and after a job runs:

yaml
default:
  before_script:
    - echo "Before script section"
  after_script:
    - echo "After script section"

job1:
  script:
    - echo "My script"

Cache

Used to store and reuse files between builds:

yaml
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/
    - .npm/

Naming conventions: Cache keys usually use a combination of variables:

  • ${CI_COMMIT_REF_SLUG} - Based on branch.
  • ${CI_JOB_NAME}-${CI_COMMIT_REF_SLUG} - Based on job and branch.

Artifacts

Files generated after jobs complete, which can be downloaded or used by subsequent jobs:

yaml
build-job:
  stage: build
  script:
    - echo "Creating artifacts..."
    - mkdir -p build/
    - touch build/info.txt
  artifacts:
    paths:
      - build/
    expire_in: 1 week

Dependencies

Defines which jobs' artifacts a job uses:

yaml
test-job:
  stage: test
  dependencies:
    - build-job
  script:
    - echo "Testing with artifacts from build-job"

Workflow

Workflow controls the execution conditions of the entire pipeline. Unlike job-level rules, workflow:rules determines whether the entire pipeline should be created. If no rules match or all rules evaluate to when:never, the entire pipeline will not run.

Basic Syntax

yaml
workflow:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: always
    - if: $CI_MERGE_REQUEST_IID
      when: always
    - if: $CI_COMMIT_TAG
      when: always
    - when: never

Meaning of the example above:

  • Run the pipeline whenever there is a commit to the main branch.
  • Run the pipeline whenever there is a merge request.
  • Run the pipeline whenever there is a tag.
  • Do not run the pipeline in other cases.

Naming the Pipeline

You can assign a name to the pipeline, which is displayed in the GitLab interface:

yaml
workflow:
  name: "Main Pipeline"

You can also use variables in the name:

yaml
workflow:
  name: "$CI_COMMIT_REF_NAME Deployment"

Rule Conditions

Workflow rules support the same conditions as job rules:

yaml
workflow:
  rules:
    # Run only on scheduled pipelines
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: always

    # Run only on pushes to specific branches
    - if: $CI_COMMIT_BRANCH == "release/*"
      when: always

    # Run based on file changes
    - if: $CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_TITLE =~ /docs:/
      changes:
        - docs/**/*
      when: always

    # Run when the configuration file itself is modified
    - changes:
      - .gitlab-ci.yml
      when: always

    # Set variables
    - if: $CI_COMMIT_BRANCH == "develop"
      variables:
        IS_DEVELOPMENT: "true"
      when: always

    # Default case
    - when: never

Practical Examples

  1. Decide whether to run the pipeline based on the commit message:
yaml
workflow:
  rules:
    - if: $CI_COMMIT_TITLE =~ /\[skip ci\]/
      when: never
    - if: $CI_COMMIT_TITLE =~ /\[run ci\]/
      when: always
    - when: on_success
  1. Run different pipelines based on project path changes:
yaml
workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - frontend/**/*
      variables:
        PIPELINE_TYPE: "frontend"
      when: always
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - backend/**/*
      variables:
        PIPELINE_TYPE: "backend"
      when: always
    - when: never
  1. Automatically run the pipeline only during working hours:
yaml
workflow:
  rules:
    # Working days (Monday to Friday)
    - if: $CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_BRANCH == "main"
      when: always
    # Working hours (9:00 - 18:00)
    - if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "main" && $HOUR >= 9 && $HOUR < 18
      when: always
    # Manual trigger required outside working hours
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
      allow_failure: true
    - when: never

Notes

  1. workflow:rules is global and affects the entire pipeline.
  2. If workflow:rules is not set, GitLab uses default rules, meaning all pushes and merge requests trigger a pipeline.
  3. When using when:never in workflow:rules, the entire pipeline will not execute, rather than just skipping the rule.
  4. Workflow rules are evaluated in order; once a matching rule is found, evaluation stops.
  5. Variables set in the workflow can be accessed by all jobs.

Needs

Allows a job to run immediately after specified jobs complete, without waiting for the entire stage to finish:

yaml
job2:
  stage: test
  needs:
    - job1
  script:
    - echo "This job runs after job1, even if they're in the same stage"

Services

Defines an additional Docker container, typically used to provide services like databases:

yaml
test:
  services:
    - postgres:13
  script:
    - echo "Testing with Postgres service"

Includes

Imports configuration from other files:

yaml
include:
  - local: '/templates/ci-template.yml'
  - project: 'my-group/my-project'
    file: '/templates/ci-template.yml'
  - template: Auto-DevOps.gitlab-ci.yml

Templates

Uses YAML anchors and aliases to create reusable templates:

yaml
# Define template (jobs starting with a dot are not executed)
.build_template: &build_definition
  stage: build
  script:
    - echo "Building using template"
  tags:
    - docker

# Use template
build_job1:
  <<: *build_definition
  script:
    - echo "Building job 1"
    - make build

# Extend template
build_job2:
  <<: *build_definition
  script:
    - echo "Building job 2"
    - make special-build
  variables:
    BUILD_TYPE: "special"

Naming conventions:

  • Template job names start with a dot, e.g., .build_template.
  • Template anchors usually use _definition or _template suffixes.

Predefined Environment Variables List

The following content is excerpted from the Predefined CI/CD variables reference. I used Claude to help translate it into Chinese for my own reference.

Scope Description

ScopeDescription
Pre-pipelineVariables that exist before the pipeline is created; available to all jobs.
PipelineVariables generated after the pipeline is created; available to all jobs.
Job-onlyVariables available only in the execution environment of a specific job.

ChatOps and Basic CI Variables

VariableScopeDescription
CHAT_CHANNELPipelineThe chat channel that triggered the ChatOps command.
CHAT_INPUTPipelineAdditional parameters passed with the ChatOps command.
CHAT_USER_IDPipelineThe user ID of the user who triggered the ChatOps command in the chat service.
CIPre-pipelineAvailable in all CI/CD jobs. Set to true when available.
CI_API_V4_URLPre-pipelineGitLab API v4 root URL.
CI_API_GRAPHQL_URLPre-pipelineGitLab API GraphQL root URL. Introduced in GitLab 15.11.
CI_DEBUG_TRACEPipelinetrue if debug logging (tracing) is enabled.
CI_DEBUG_SERVICESPipelinetrue if service container logging is enabled. Introduced in GitLab 15.7. Requires GitLab Runner 15.7.
GITLAB_CIPre-pipelineAvailable in all CI/CD jobs. Set to true when available.
GITLAB_FEATURESPre-pipelineComma-separated list of licensed features available to the GitLab instance and license.
VariableScopeDescription
CI_BUILDS_DIRJob-onlyThe top-level directory where builds are executed.
CI_COMMIT_AUTHORPre-pipelineThe author of the commit, in the format Name <email>.
CI_COMMIT_BEFORE_SHAPre-pipelineThe previous latest commit on the branch or tag. Always 0000000000000000000000000000000000000000 for merge request pipelines, scheduled pipelines, the first commit of a branch or tag, or manual pipelines.
CI_COMMIT_BRANCHPre-pipelineThe commit branch name. Available in branch pipelines, including default branch pipelines. Not available in merge request or tag pipelines.
CI_COMMIT_DESCRIPTIONPre-pipelineThe commit description. If the title is less than 100 characters, it is the message excluding the first line.
CI_COMMIT_MESSAGEPre-pipelineThe full commit message.
CI_COMMIT_REF_NAMEPre-pipelineThe branch or tag name for which the project is built.
CI_COMMIT_REF_PROTECTEDPre-pipelinetrue if the job is running for a protected reference, false otherwise.
CI_COMMIT_REF_SLUGPre-pipelineLowercase version of CI_COMMIT_REF_NAME, truncated to 63 bytes, with all characters except 0-9 and a-z replaced by -. No leading/trailing -. Used for URLs, hostnames, and domain names.
CI_COMMIT_SHAPre-pipelineThe commit revision for which the project is built.
CI_COMMIT_SHORT_SHAPre-pipelineThe first eight characters of CI_COMMIT_SHA.
CI_COMMIT_TAGPre-pipelineThe commit tag name. Available only in tag pipelines.
CI_COMMIT_TAG_MESSAGEPre-pipelineThe commit tag message. Available only in tag pipelines. Introduced in GitLab 15.5.
CI_COMMIT_TIMESTAMPPre-pipelineThe commit timestamp in ISO 8601 format. For example, 2022-01-31T16:47:55Z. Defaults to UTC.
CI_COMMIT_TITLEPre-pipelineThe commit title. The full first line of the message.
CI_OPEN_MERGE_REQUESTSPre-pipelineComma-separated list of up to four merge requests using the current branch and project as the source. Available only in branch and merge request pipelines if the branch has associated merge requests. For example, gitlab-org/gitlab!333,gitlab-org/gitlab-foss!11.
VariableScopeDescription
CI_CONFIG_PATHPre-pipelinePath to the CI/CD configuration file. Defaults to .gitlab-ci.yml.
CI_CONCURRENT_IDJob-onlyUnique ID for build execution in a single runner.
CI_CONCURRENT_PROJECT_IDJob-onlyUnique ID for build execution in a single runner and project.
CI_DEFAULT_BRANCHPre-pipelineThe project's default branch name.
CI_PROJECT_DIRJob-onlyThe full path where the repository is cloned and the job is executed. If the GitLab Runner builds_dir parameter is set, this variable is relative to that value. See advanced GitLab Runner configuration for more info.
CI_REPOSITORY_URLJob-onlyThe full path to clone the repository (HTTP) using the CI/CD job token, in the format https://gitlab-ci-token:[email protected]/my-group/my-project.git.
VariableScopeDescription
CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIXPre-pipelineDirect group image prefix for pulling images through the dependency proxy.
CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIXPre-pipelineTop-level group image prefix for pulling images through the dependency proxy.
CI_DEPENDENCY_PROXY_PASSWORDPipelinePassword for pulling images through the dependency proxy.
CI_DEPENDENCY_PROXY_SERVERPre-pipelineServer for logging into the dependency proxy. This variable is equivalent to $CI_SERVER_HOST:$CI_SERVER_PORT.
CI_DEPENDENCY_PROXY_USERPipelineUsername for pulling images through the dependency proxy.
VariableScopeDescription
CI_DEPLOY_FREEZEPre-pipelineAvailable only if the pipeline runs during a deployment freeze window. true when available.
CI_DEPLOY_PASSWORDJob-onlyAuthentication password for the GitLab Deploy Token, if the project has one.
CI_DEPLOY_USERJob-onlyAuthentication username for the GitLab Deploy Token, if the project has one.
CI_DISPOSABLE_ENVIRONMENTPipelineAvailable only if the job runs in a disposable environment (environments created only for this job and destroyed after execution - all executors except shell and ssh). true when available.
CI_ENVIRONMENT_NAMEPipelineThe environment name for this job. Available if environment:name is set.
CI_ENVIRONMENT_SLUGPipelineA simplified version of the environment name, suitable for inclusion in DNS, URLs, Kubernetes labels, etc. Available if environment:name is set. The slug is truncated to 24 characters. For uppercase environment names, a random suffix is automatically added.
CI_ENVIRONMENT_URLPipelineThe environment URL for this job. Available if environment:url is set.
CI_ENVIRONMENT_ACTIONPipelineThe action note specified for this job's environment. Available if environment:action is set. Can be start, prepare, or stop.
CI_ENVIRONMENT_TIERPipelineThe deployment tier for this job's environment.
CI_KUBERNETES_ACTIVEPre-pipelineAvailable only if the pipeline has a Kubernetes cluster available for deployment. true when available.
CI_RELEASE_DESCRIPTIONPipelineThe release description. Available only in tag pipelines. Description length is limited to the first 1024 characters. Introduced in GitLab 15.5.
KUBECONFIGPipelinePath to the kubeconfig file containing environment settings for each shared agent connection. Available only if the GitLab agent is authorized to access the project.
VariableScopeDescription
CI_GITLAB_FIPS_MODEPre-pipelineAvailable only if FIPS mode is enabled in the GitLab instance. true when available.
CI_HAS_OPEN_REQUIREMENTSPipelineAvailable only if the pipeline's project has open requirements. true when available.
CI_JOB_GROUP_NAMEPipelineShared name for job groups when using parallel or manual grouped jobs. For example, if the job name is rspec:test: [ruby, ubuntu], CI_JOB_GROUP_NAME is rspec:test. Otherwise, it is the same as CI_JOB_NAME. Introduced in GitLab 17.10.
CI_JOB_IDJob-onlyThe internal ID of the job, unique across all jobs in the GitLab instance.
CI_JOB_IMAGEPipelineThe Docker image name used to execute the job.
CI_JOB_MANUALPipelineAvailable only if the job was started manually. true when available.
CI_JOB_NAMEPipelineThe name of the job.
CI_JOB_NAME_SLUGPipelineLowercase version of CI_JOB_NAME, truncated to 63 bytes, with all characters except 0-9 and a-z replaced by -. No leading/trailing -. Used for paths. Introduced in GitLab 15.4.
CI_JOB_STAGEPipelineThe stage name of the job.
CI_JOB_STATUSJob-onlyThe status of the job while each runner stage is executing. Used with after_script. Can be success, failed, or canceled.
CI_JOB_TIMEOUTJob-onlyJob timeout in seconds. Introduced in GitLab 15.7. Requires GitLab Runner 15.7.
CI_JOB_TOKENJob-onlyToken used to authenticate certain API endpoints. The token is valid during the job execution.
CI_JOB_URLJob-onlyJob details URL.
CI_JOB_STARTED_ATJob-onlyThe date and time the job started, in ISO 8601 format. For example, 2022-01-31T16:47:55Z. Defaults to UTC.
CI_NODE_INDEXPipelineThe index of the job in the job set. Available only when the job uses parallel.
CI_NODE_TOTALPipelineThe total number of instances the job is running in parallel. If the job does not use parallel, it is set to 1.
VariableScopeDescription
CI_PAGES_DOMAINPre-pipelineThe instance domain hosting GitLab Pages, excluding the namespace subdomain. To use the full hostname, use CI_PAGES_HOSTNAME.
CI_PAGES_HOSTNAMEJob-onlyThe full hostname where Pages are deployed.
CI_PAGES_URLJob-onlyThe URL of the GitLab Pages site. Always a subdomain of CI_PAGES_DOMAIN. In GitLab 17.9 and later, when path_prefix is specified, the value includes the path_prefix.
VariableScopeDescription
CI_PIPELINE_IDJob-onlyThe instance-level ID of the current pipeline. This ID is unique across all projects in the GitLab instance.
CI_PIPELINE_IIDPipelineThe project-level IID (internal ID) of the current pipeline. This ID is unique only within the current project.
CI_PIPELINE_SOURCEPre-pipelineThe trigger method of the pipeline. The value can be one of the pipeline sources.
CI_PIPELINE_TRIGGEREDPipelinetrue if the job was triggered.
CI_PIPELINE_URLJob-onlyPipeline details URL.
CI_PIPELINE_CREATED_ATPre-pipelineThe date and time the pipeline was created, in ISO 8601 format. For example, 2022-01-31T16:47:55Z. Defaults to UTC.
CI_PIPELINE_NAMEPre-pipelineThe pipeline name defined in workflow:name. Introduced in GitLab 16.3.
CI_PIPELINE_SCHEDULE_DESCRIPTIONPre-pipelineThe description of the pipeline schedule. Available only in scheduled pipelines. Introduced in GitLab 17.8.
VariableScopeDescription
CI_PROJECT_IDPre-pipelineThe ID of the current project. This ID is unique across all projects in the GitLab instance.
CI_PROJECT_NAMEPre-pipelineThe name of the project directory. For example, if the project URL is gitlab.example.com/group-name/project-1, CI_PROJECT_NAME is project-1.
CI_PROJECT_NAMESPACEPre-pipelineThe project namespace (username or group name) of the job.
CI_PROJECT_NAMESPACE_IDPre-pipelineThe project namespace ID of the job. Introduced in GitLab 15.7.
CI_PROJECT_NAMESPACE_SLUGPre-pipelineLowercase version of $CI_PROJECT_NAMESPACE, with characters that are not a-z or 0-9 replaced by - and truncated to 63 bytes.
CI_PROJECT_PATH_SLUGPre-pipelineLowercase version of $CI_PROJECT_PATH, with characters that are not a-z or 0-9 replaced by - and truncated to 63 bytes. Used for URLs and domain names.
CI_PROJECT_PATHPre-pipelineThe project namespace including the project name.
CI_PROJECT_REPOSITORY_LANGUAGESPre-pipelineA comma-separated, lowercase list of languages used in the repository. For example, ruby,javascript,html,css. The maximum number of languages is limited to 5. There is an issue proposing to increase this limit.
CI_PROJECT_ROOT_NAMESPACEPre-pipelineThe root project namespace (username or group name) of the job. For example, if CI_PROJECT_NAMESPACE is root-group/child-group/grandchild-group, CI_PROJECT_ROOT_NAMESPACE is root-group.
CI_PROJECT_TITLEPre-pipelineThe human-readable project name displayed in the GitLab Web interface.
CI_PROJECT_DESCRIPTIONPre-pipelineThe project description displayed in the GitLab Web interface. Introduced in GitLab 15.1.
CI_PROJECT_URLPre-pipelineThe HTTP(S) URL of the project.
CI_PROJECT_VISIBILITYPre-pipelineProject visibility. Can be internal, private, or public.
CI_PROJECT_CLASSIFICATION_LABELPre-pipelineThe project's external authorization classification label.
VariableScopeDescription
CI_REGISTRYPre-pipelineThe URL of the container registry server, in the format <host>[:<port>]. For example: registry.gitlab.example.com. Available only if the container registry is enabled for the GitLab instance.
CI_REGISTRY_IMAGEPre-pipelineThe base URL of the container registry for pushing, pulling, or tagging project images, in the format <host>[:<port>]/<project_full_path>. For example: registry.gitlab.example.com/my_group/my_project. The image name must follow container registry naming conventions. Available only if the container registry is enabled for the project.
CI_REGISTRY_PASSWORDJob-onlyPassword for pushing containers to the GitLab project's container registry. Available only if the container registry is enabled for the project. This password value is the same as CI_JOB_TOKEN and is valid only during the job execution. Use CI_DEPLOY_PASSWORD for long-term registry access.
CI_REGISTRY_USERJob-onlyUsername for pushing containers to the project's GitLab container registry. Available only if the container registry is enabled for the project.
CI_TEMPLATE_REGISTRY_HOSTPre-pipelineThe registry host used by CI/CD templates. Defaults to registry.gitlab.com. Introduced in GitLab 15.3.
VariableScopeDescription
CI_RUNNER_DESCRIPTIONJob-onlyThe description of the runner.
CI_RUNNER_EXECUTABLE_ARCHJob-onlyThe OS/architecture of the GitLab Runner executable. May differ from the executor's environment.
CI_RUNNER_IDJob-onlyThe unique ID of the runner being used.
CI_RUNNER_REVISIONJob-onlyThe revision of the runner executing the job.
CI_RUNNER_SHORT_TOKENJob-onlyThe unique ID of the runner, used to authenticate new job requests. The token includes a prefix; use the first 17 characters.
CI_RUNNER_TAGSJob-onlyA JSON array of runner tags. For example ["tag_1", "tag_2"].
CI_RUNNER_VERSIONJob-onlyThe version of the GitLab Runner executing the job.
CI_SHARED_ENVIRONMENTPipelineAvailable only if the job runs in a shared environment (an environment that persists between CI/CD invocations, such as shell or ssh executors). true when available.
VariableScopeDescription
CI_SERVER_FQDNPre-pipelineThe Fully Qualified Domain Name (FQDN) of the instance. For example gitlab.example.com:8080. Introduced in GitLab 16.10.
CI_SERVER_HOSTPre-pipelineThe host of the GitLab instance URL, excluding the protocol or port. For example gitlab.example.com.
CI_SERVER_NAMEPre-pipelineThe name of the CI/CD server coordinating the job.
CI_SERVER_PORTPre-pipelineThe port of the GitLab instance URL, excluding the host or protocol. For example 8080.
CI_SERVER_PROTOCOLPre-pipelineThe protocol of the GitLab instance URL, excluding the host or port. For example https.
CI_SERVER_SHELL_SSH_HOSTPre-pipelineThe SSH host of the GitLab instance, used for accessing Git repositories via SSH. For example gitlab.com. Introduced in GitLab 15.11.
CI_SERVER_SHELL_SSH_PORTPre-pipelineThe SSH port of the GitLab instance, used for accessing Git repositories via SSH. For example 22. Introduced in GitLab 15.11.
CI_SERVER_REVISIONPre-pipelineThe GitLab revision that scheduled the job.
CI_SERVER_TLS_CA_FILEPipelineFile containing the TLS CA certificate, used to verify the GitLab server when tls-ca-file is set in the runner configuration.
CI_SERVER_TLS_CERT_FILEPipelineFile containing the TLS certificate, used to verify the GitLab server when tls-cert-file is set in the runner configuration.
CI_SERVER_TLS_KEY_FILEPipelineFile containing the TLS key, used to verify the GitLab server when tls-key-file is set in the runner configuration.
CI_SERVER_URLPre-pipelineThe base URL of the GitLab instance, including the protocol and port. For example https://gitlab.example.com:8080.
CI_SERVER_VERSION_MAJORPre-pipelineThe major version of the GitLab instance. For example, if the GitLab version is 17.2.1, CI_SERVER_VERSION_MAJOR is 17.
CI_SERVER_VERSION_MINORPre-pipelineThe minor version of the GitLab instance. For example, if the GitLab version is 17.2.1, CI_SERVER_VERSION_MINOR is 2.
CI_SERVER_VERSION_PATCHPre-pipelineThe patch version of the GitLab instance. For example, if the GitLab version is 17.2.1, CI_SERVER_VERSION_PATCH is 1.
CI_SERVER_VERSIONPre-pipelineThe full version of the GitLab instance.
CI_SERVERJob-onlyAvailable in all CI/CD jobs. Set to yes when available.
VariableScopeDescription
CI_TRIGGER_SHORT_TOKENJob-onlyThe first 4 characters of the trigger token for the current job. Available only if the pipeline was triggered by a trigger token. For example, for trigger token glptt-1234567890abcdefghij, CI_TRIGGER_SHORT_TOKEN is 1234. Introduced in GitLab 17.0.
GITLAB_USER_EMAILPipelineThe email of the user who started the pipeline, unless the job is a manual job. In a manual job, the value is the email of the user who started the job.
GITLAB_USER_IDPipelineThe numeric ID of the user who started the pipeline, unless the job is a manual job. In a manual job, the value is the ID of the user who started the job.
GITLAB_USER_LOGINPipelineThe unique username of the user who started the pipeline, unless the job is a manual job. In a manual job, the value is the username of the user who started the job.
GITLAB_USER_NAMEPipelineThe display name of the user who started the pipeline (the full name defined in the user's profile settings), unless the job is a manual job. In a manual job, the value is the name of the user who started the job.
TRIGGER_PAYLOADPipelineWebhook data payload. Available only when the pipeline is triggered using a webhook.
VariableDescription
CI_MERGE_REQUEST_APPROVEDApproval status of the merge request. true when merge request approval is available and the merge request has been approved.
CI_MERGE_REQUEST_ASSIGNEESComma-separated list of usernames of the merge request assignees. Available only if the merge request has at least one assignee.
CI_MERGE_REQUEST_DIFF_BASE_SHAThe base SHA of the merge request diff.
CI_MERGE_REQUEST_DIFF_IDThe version of the merge request diff.
CI_MERGE_REQUEST_EVENT_TYPEThe event type of the merge request. Can be detached, merged_result, or merge_train.
CI_MERGE_REQUEST_DESCRIPTIONThe description of the merge request. If the description length exceeds 2700 characters, only the first 2700 characters are stored in the variable. Introduced in GitLab 16.7.
CI_MERGE_REQUEST_DESCRIPTION_IS_TRUNCATEDtrue if CI_MERGE_REQUEST_DESCRIPTION was truncated to 2700 characters because the merge request description was too long, false otherwise. Introduced in GitLab 16.8.
CI_MERGE_REQUEST_IDThe instance-level ID of the merge request. This ID is unique across all projects in the GitLab instance.
CI_MERGE_REQUEST_IIDThe project-level IID (internal ID) of the merge request. This ID is unique within the current project and is the number used in the merge request URL, page title, and other visible locations.
CI_MERGE_REQUEST_LABELSComma-separated list of label names for the merge request. Available only if the merge request has at least one label.
CI_MERGE_REQUEST_MILESTONEThe milestone title of the merge request. Available only if a milestone is set for the merge request.
CI_MERGE_REQUEST_PROJECT_IDThe project ID of the merge request.
CI_MERGE_REQUEST_PROJECT_PATHThe project path of the merge request. For example namespace/awesome-project.
CI_MERGE_REQUEST_PROJECT_URLThe project URL of the merge request. For example http://192.168.10.15:3000/namespace/awesome-project.
CI_MERGE_REQUEST_REF_PATHThe reference path of the merge request. For example refs/merge-requests/1/head.
CI_MERGE_REQUEST_SOURCE_BRANCH_NAMEThe source branch name of the merge request.
CI_MERGE_REQUEST_SOURCE_BRANCH_PROTECTEDtrue when the merge request's source branch is protected. Introduced in GitLab 16.4.
CI_MERGE_REQUEST_SOURCE_BRANCH_SHAThe HEAD SHA of the merge request's source branch. In merge request pipelines, the variable is empty. The SHA appears only in merged result pipelines.
CI_MERGE_REQUEST_SOURCE_PROJECT_IDThe source project ID of the merge request.
CI_MERGE_REQUEST_SOURCE_PROJECT_PATHThe source project path of the merge request.
CI_MERGE_REQUEST_SOURCE_PROJECT_URLThe source project URL of the merge request.
CI_MERGE_REQUEST_SQUASH_ON_MERGEtrue when the squash on merge option is set. Introduced in GitLab 16.4.
CI_MERGE_REQUEST_TARGET_BRANCH_NAMEThe target branch name of the merge request.
CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTEDtrue when the merge request's target branch is protected. Introduced in GitLab 15.2.
CI_MERGE_REQUEST_TARGET_BRANCH_SHAThe HEAD SHA of the merge request's target branch. In merge request pipelines, the variable is empty. The SHA appears only in merged result pipelines.
CI_MERGE_REQUEST_TITLEThe title of the merge request.
CI_MERGE_REQUEST_DRAFTtrue if the merge request is a draft. Introduced in GitLab 17.10.
VariableDescription
CI_EXTERNAL_PULL_REQUEST_IIDPull request ID from GitHub.
CI_EXTERNAL_PULL_REQUEST_SOURCE_REPOSITORYThe source repository name of the pull request.
CI_EXTERNAL_PULL_REQUEST_TARGET_REPOSITORYThe target repository name of the pull request.
CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_NAMEThe source branch name of the pull request.
CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_SHAThe HEAD SHA of the pull request's source branch.
CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_NAMEThe target branch name of the pull request.
CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_SHAThe HEAD SHA of the pull request's target branch.
CI_EXTERNAL_PULL_REQUEST_LABELSComma-separated list of labels for the pull request. Available only if the merge request has at least one label.
CI_EXTERNAL_PULL_REQUEST_TITLEThe title of the pull request.
CI_EXTERNAL_PULL_REQUEST_DESCRIPTIONThe description of the pull request.
CI_EXTERNAL_PULL_REQUEST_HTML_URLThe HTML URL of the pull request.

Integration Variables

The following integration variables are available in jobs as "job-only" predefined variables:

Harbor

VariableDescription
HARBOR_URLURL of the Harbor instance.
HARBOR_HOSTHostname of the Harbor instance.
HARBOR_OCIHarbor OCI connection settings.
HARBOR_PROJECTTarget Harbor project name.
HARBOR_USERNAMEHarbor authentication username.
HARBOR_PASSWORDHarbor authentication password.

Apple App Store Connect

VariableDescription
APP_STORE_CONNECT_API_KEY_ISSUER_IDApple App Store Connect API key issuer ID.
APP_STORE_CONNECT_API_KEY_KEY_IDApple App Store Connect API key ID.
APP_STORE_CONNECT_API_KEY_KEYApple App Store Connect API key content.
APP_STORE_CONNECT_API_KEY_IS_KEY_CONTENT_BASE64Indicates whether the API key content is Base64 encoded.

Google Play

VariableDescription
SUPPLY_PACKAGE_NAMEPackage name of the Android application.
SUPPLY_JSON_KEY_DATAJSON key data for Google Play API access.

Diffblue Cover

VariableDescription
DIFFBLUE_LICENSE_KEYLicense key for Diffblue Cover.
DIFFBLUE_ACCESS_TOKEN_NAMEDiffblue access token name.
DIFFBLUE_ACCESS_TOKENDiffblue access token.

Changelog

  • 2025-04-07 Initial document creation.