When you are editing your .gitlab-ci.yml file, you can validate it with the CI Lint tool.

If you are editing content on this page, follow the instructions for documenting keywords .

Global keywords that configure pipeline behavior:

Example of default :

default:
  image: ruby:3.0
rspec:
  script: bundle exec rspec
rspec 2.7:
  image: ruby:2.7
  script: bundle exec rspec

In this example, ruby:3.0 is the default image value for all jobs in the pipeline. The rspec 2.7 job does not use the default, because it overrides the default with a job-specific image section:

Additional details :

Moved to GitLab Free in 11.4.

Use include to include external YAML files in your CI/CD configuration. You can split one long .gitlab-ci.yml file into multiple files to increase readability, or reduce duplication of the same configuration in multiple places.

You can also store template files in a central repository and include them in projects.

The include files are:

The time limit to resolve all files is 30 seconds.

Keyword type : Global keyword.

Possible inputs : The include subkeys:

Additional details :

Related topics :

Example of include:local :

include:
  - local: '/templates/.gitlab-ci-template.yml'

You can also use shorter syntax to define the path:

include: '.gitlab-ci-production.yml'

Additional details :

Including multiple files from the same project introduced in GitLab 13.6. Feature flag removed in GitLab 13.8.

To include files from another private project on the same GitLab instance, use include:project and include:file .

Keyword type : Global keyword.

Possible inputs :

Example of include:project :

include:
  - project: 'my-group/my-project'
    file: '/templates/.gitlab-ci-template.yml'
  - project: 'my-group/my-subgroup/my-project-2'
    file:
      - '/templates/.builds.yml'
      - '/templates/.tests.yml'

You can also specify a ref :

include:
  - project: 'my-group/my-project'
    ref: main                                      # Git branch
    file: '/templates/.gitlab-ci-template.yml'
  - project: 'my-group/my-project'
    ref: v1.0.0                                    # Git Tag
    file: '/templates/.gitlab-ci-template.yml'
  - project: 'my-group/my-project'
    ref: 787123b47f14b552955ca2786bc9542ae66fee5b  # Git SHA
    file: '/templates/.gitlab-ci-template.yml'

Additional details :

Example of include:remote :

include:
  - remote: 'https://gitlab.com/example-project/-/raw/main/.gitlab-ci.yml'

Additional details :

Use include:template to include .gitlab-ci.yml templates .

Keyword type : Global keyword.

Possible inputs :

A CI/CD template :

Example of include:template :

# File sourced from the GitLab template collection
include:
  - template: Auto-DevOps.gitlab-ci.yml

Multiple include:template files:

include:
  - template: Android-Fastlane.gitlab-ci.yml
  - template: Auto-DevOps.gitlab-ci.yml

Additional details :

Use stages to define stages that contain groups of jobs. Use stage in a job to configure the job to run in a specific stage.

If stages is not defined in the .gitlab-ci.yml file, the default pipeline stages are:

The order of the items in stages defines the execution order for jobs:

If a pipeline contains only jobs in the .pre or .post stages, it does not run. There must be at least one other job in a different stage. .pre and .post stages can be used in required pipeline configuration to define compliance jobs that must run before or after project pipeline jobs.

Keyword type : Global keyword.

Example of stages :

stages:
  - build
  - test
  - deploy

In this example:

If any job fails, the pipeline is marked as failed and jobs in later stages do not start. Jobs in the current stage are not stopped and continue to run.

Additional details :

Related topics :

Introduced in GitLab 12.5

Use workflow to control pipeline behavior.

Related topics :

You can use name in workflow: to define a name for pipelines.

All pipelines are assigned the defined name. Any leading or trailing spaces in the name are removed.

Possible inputs :

Examples of workflow:name :

A simple pipeline name with a predefined variable:

workflow:
  name: 'Pipeline for branch: $CI_COMMIT_BRANCH'

A configuration with different pipeline names depending on the pipeline conditions:

variables:
  PROJECT1_PIPELINE_NAME: 'Default pipeline name'  # A default is not required.
workflow:
  name: '$PROJECT1_PIPELINE_NAME'
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      variables:
        PROJECT1_PIPELINE_NAME: 'MR pipeline: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME'
    - if: '$CI_MERGE_REQUEST_LABELS =~ /pipeline:run-in-ruby3/'
      variables:
        PROJECT1_PIPELINE_NAME: 'Ruby 3 pipeline'

Additional details :

The rules keyword in workflow is similar to rules defined in jobs , but controls whether or not a whole pipeline is created.

When no rules evaluate to true, the pipeline does not run.

Possible inputs : You can use some of the same keywords as job-level rules :

Example of workflow:rules :

workflow:
  rules:
    - if: $CI_COMMIT_TITLE =~ /-draft$/
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

In this example, pipelines run if the commit title (first line of the commit message) does not end with -draft and the pipeline is for either:

Additional details :

Related topics :

You can use variables in workflow:rules to define variables for specific pipeline conditions.

When the condition matches, the variable is created and can be used by all jobs in the pipeline. If the variable is already defined at the global level, the workflow variable takes precedence and overrides the global variable.

Keyword type : Global keyword.

Possible inputs : Variable name and value pairs:

Example of workflow:rules:variables :

variables:
  DEPLOY_VARIABLE: "default-deploy"
workflow:
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        DEPLOY_VARIABLE: "deploy-production"  # Override globally-defined DEPLOY_VARIABLE
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # Define a new variable.
    - when: always                            # Run the pipeline in other cases
job1:
  variables:
    DEPLOY_VARIABLE: "job1-default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                                   # Override DEPLOY_VARIABLE defined
        DEPLOY_VARIABLE: "job1-deploy-production"  # at the job level.
    - when: on_success                             # Run the job in other cases
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"
job2:
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

When the branch is the default branch:

When the branch is feature :

When the branch is something else:

Additional details :

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs : An array including:

CI/CD variables are supported .

Example of after_script :

job:
  script:
    - echo "An example script section."
  after_script:
    - echo "Execute this command after the `script` section completes."

Additional details :

Scripts you specify in after_script execute in a new shell, separate from any before_script or script commands. As a result, they:

If a job times out or is cancelled, the after_script commands do not execute. An issue exists to add support for executing after_script commands for timed-out or cancelled jobs.

Related topics :

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of allow_failure :

job1:
  stage: test
  script:
    - execute_script_1
job2:
  stage: test
  script:
    - execute_script_2
  allow_failure: true
job3:
  stage: deploy
  script:
    - deploy_to_staging
  environment: staging

In this example, job1 and job2 run in parallel:

Additional details :

test_job_1:
  script:
    - echo "Run a script that results in exit code 1. This job fails."
    - exit 1
  allow_failure:
    exit_codes: 137
test_job_2:
  script:
    - echo "Run a script that results in exit code 137. This job is allowed to fail."
    - exit 137
  allow_failure:
    exit_codes:
      - 137
      - 255

Use artifacts to specify which files to save as job artifacts . Job artifacts are a list of files and directories that are attached to the job when it succeeds, fails, or always .

The artifacts are sent to GitLab after the job finishes. They are available for download in the GitLab UI if the size is smaller than the maximum artifact size .

By default, jobs in later stages automatically download all the artifacts created by jobs in earlier stages. You can control artifact download behavior in jobs with dependencies .

When using the needs keyword, jobs can only download artifacts from the jobs defined in the needs configuration.

Job artifacts are only collected for successful jobs by default, and artifacts are restored after caches .

Read more about artifacts .

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of artifacts:paths :

job:
  artifacts:
    paths:
      - binaries/
      - .config

This example creates an artifact with .config and all the files in the binaries directory.

Additional details :

Related topics :

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of artifacts:exclude :

artifacts:
  paths:
    - binaries/
  exclude:
    - binaries/**/*.o

This example stores all files in binaries/ , but not *.o files located in subdirectories of binaries/ .

Additional details :

Related topics :

Use expire_in to specify how long job artifacts are stored before they expire and are deleted. The expire_in setting does not affect:

After their expiry, artifacts are deleted hourly by default (using a cron job), and are not accessible anymore.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs : The expiry time. If no unit is provided, the time is in seconds. Valid values include:

Example of artifacts:expire_in :

job:
  artifacts:
    expire_in: 1 week

Additional details :

Use the artifacts:expose_as keyword to expose job artifacts in the merge request UI .

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of artifacts:expose_as :

test:
  script: ["echo 'test' > file.txt"]
  artifacts:
    expose_as: 'artifact 1'
    paths: ['file.txt']

Additional details :

Related topics :

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of artifacts:name :

To create an archive with a name of the current job:

job:
  artifacts:
    name: "job1-artifacts-file"
    paths:
      - binaries/

Related topics :

WARNING: On self-managed GitLab, by default this feature is not available. To make it available, an administrator can enable the feature flag named non_public_artifacts . On GitLab.com, this feature is not available. Due to issue 413822 , the keyword can be used when the feature flag is disabled, but the feature does not work. Do not attempt to use this feature when the feature flag is disabled, and always test with non-production data first.

Use artifacts:public to determine whether the job artifacts should be publicly available.

When artifacts:public is true (default), the artifacts in public pipelines are available for download by anonymous and guest users.

To deny read access for anonymous and guest users to artifacts in public pipelines, set artifacts:public to false :

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of artifacts:public :

job:
  artifacts:
    public: false

Use artifacts:reports to collect artifacts generated by included templates in jobs.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of artifacts:reports :

rspec:
  stage: test
  script:
    - bundle install
    - rspec --format RspecJunitFormatter --out rspec.xml
  artifacts:
    reports:
      junit: rspec.xml

Additional details :

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of artifacts:untracked :

Save all Git untracked files:

job:
  artifacts:
    untracked: true

Related topics :

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of artifacts:when :

job:
  artifacts:
    when: on_failure

Additional details :

Use before_script to define an array of commands that should run before each job's script commands, but after artifacts are restored.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs : An array including:

CI/CD variables are supported .

Example of before_script :

job:
  before_script:
    - echo "Execute this command before any 'script:' commands."
  script:
    - echo "This command executes after the job's 'before_script' commands."

Additional details :

Related topics :

Introduced in GitLab 15.0, caches are not shared between protected and unprotected branches.

Use cache to specify a list of files and directories to cache between jobs. You can only use paths that are in the local working copy.

Caches are:

You can disable caching for specific jobs , for example to override:

For more information about caches, see Caching in GitLab CI/CD .

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of cache:paths :

Cache all files in binaries that end in .apk and the .config file:

rspec:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache
    paths:
      - binaries/*.apk
      - .config

Additional details :

Related topics :

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of cache:key :

cache-job:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache-$CI_COMMIT_REF_SLUG
    paths:
      - binaries/

Additional details :

If you use Windows Batch to run your shell scripts you must replace $ with % . For example: key: %CI_COMMIT_REF_SLUG%

The cache:key value can't contain:

The cache is shared between jobs, so if you're using different paths for different jobs, you should also set a different cache:key . Otherwise cache content can be overwritten.

Related topics :

Introduced in GitLab 12.5.

Use the cache:key:files keyword to generate a new key when one or two specific files change. cache:key:files lets you reuse some caches, and rebuild them less often, which speeds up subsequent pipeline runs.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of cache:key:files :

cache-job:
  script:
    - echo "This job uses a cache."
  cache:
    key:
      files:
        - Gemfile.lock
        - package.json
    paths:
      - vendor/ruby
      - node_modules

This example creates a cache for Ruby and Node.js dependencies. The cache is tied to the current versions of the Gemfile.lock and package.json files. When one of these files changes, a new cache key is computed and a new cache is created. Any future job runs that use the same Gemfile.lock and package.json with cache:key:files use the new cache, instead of rebuilding the dependencies.

Additional details :

Introduced in GitLab 12.5.

Use cache:key:prefix to combine a prefix with the SHA computed for cache:key:files .

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of cache:key:prefix :

rspec:
  script:
    - echo "This rspec job uses a cache."
  cache:
    key:
      files:
        - Gemfile.lock
      prefix: $CI_JOB_NAME
    paths:
      - vendor/ruby

For example, adding a prefix of $CI_JOB_NAME causes the key to look like rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5 . If a branch changes Gemfile.lock , that branch has a new SHA checksum for cache:key:files . A new cache key is generated, and a new cache is created for that key. If Gemfile.lock is not found, the prefix is added to default , so the key in the example would be rspec-default .

Additional details :

Caching untracked files can create unexpectedly large caches if the job downloads:

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of cache:untracked :

rspec:
  script: test
  cache:
    untracked: true

Additional details :

You can combine cache:untracked with cache:paths to cache all untracked files, as well as files in the configured paths. Use cache:paths to cache any specific files, including tracked files, or files that are outside of the working directory, and use cache: untracked to also cache all untracked files. For example:

rspec:
  script: test
  cache:
    untracked: true
    paths:
      - binaries/

In this example, the job caches all untracked files in the repository, as well as all the files in binaries/ . If there are untracked files in binaries/ , they are covered by both keywords.

Introduced in GitLab 15.8.

Use cache:unprotect to set a cache to be shared between protected and unprotected branches.

WARNING: When set to true , users without access to protected branches can read and write to cache keys used by protected branches.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of cache:unprotect :

rspec:
  script: test
  cache:
    unprotect: true

Introduced in GitLab 13.5 and GitLab Runner v13.5.0.

Use cache:when to define when to save the cache, based on the status of the job.

Must be used with cache: paths , or nothing is cached.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of cache:when :

rspec:
  script: rspec
  cache:
    paths:
      - rspec/
    when: 'always'

This example stores the cache whether or not the job fails or succeeds.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of cache:policy :

prepare-dependencies-job:
  stage: build
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: push
  script:
    - echo "This job only downloads dependencies and builds the cache."
    - echo "Downloading dependencies..."
faster-test-job:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - echo "This job script uses the cache, but does not update it."
    - echo "Running tests..."

Related topics :

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of cache:fallback_keys :

rspec:
  script: rspec
  cache:
    key: gems-$CI_COMMIT_REF_SLUG
    paths:
      - rspec/
    fallback_keys:
      - gems
    when: 'always'

job1:
  script: rspec
  coverage: '/Code coverage: \d+\.\d+/'

Introduced in GitLab 14.1.

Use the dast_configuration keyword to specify a site profile and scanner profile to be used in a CI/CD configuration. Both profiles must first have been created in the project. The job's stage must be dast .

Keyword type : Job keyword. You can use only as part of a job.

Possible inputs : One each of site_profile and scanner_profile .

Example of dast_configuration :

stages:
  - build
  - dast
include:
  - template: DAST.gitlab-ci.yml
dast:
  dast_configuration:
    site_profile: "Example Co"
    scanner_profile: "Quick Passive Test"

In this example, the dast job extends the dast configuration added with the include keyword to select a specific site profile and scanner profile.

Additional details :

Related topics :

Use the dependencies keyword to define a list of jobs to fetch artifacts from. You can also set a job to download no artifacts at all.

If you do not use dependencies , all artifacts from previous stages are passed to each job.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of dependencies :

build osx:
  stage: build
  script: make build:osx
  artifacts:
    paths:
      - binaries/
build linux:
  stage: build
  script: make build:linux
  artifacts:
    paths:
      - binaries/
test osx:
  stage: test
  script: make test:osx
  dependencies:
    - build osx
test linux:
  stage: test
  script: make test:linux
  dependencies:
    - build linux
deploy:
  stage: deploy
  script: make deploy
  environment: production

In this example, two jobs have artifacts: build osx and build linux . When test osx is executed, the artifacts from build osx are downloaded and extracted in the context of the build. The same thing happens for test linux and artifacts from build linux .

The deploy job downloads artifacts from all previous jobs because of the stage precedence.

Additional details :

Use environment to define the environment that a job deploys to.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : The name of the environment the job deploys to, in one of these formats:

Example of environment :

deploy to production:
  stage: deploy
  script: git push production HEAD:main
  environment: production

Additional details :

Set a name for an environment .

Common environment names are qa , staging , and production , but you can use any name.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : The name of the environment the job deploys to, in one of these formats:

Example of environment:name :

deploy to production:
  stage: deploy
  script: git push production HEAD:main
  environment:
    name: production

Set a URL for an environment .

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : A single URL, in one of these formats:

Example of environment:url :

deploy to production:
  stage: deploy
  script: git push production HEAD:main
  environment:
    name: production
    url: https://prod.example.com

Additional details :

Example of environment:action :

stop_review_app:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  script: make delete-app
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

Introduced in GitLab 12.8.

The auto_stop_in keyword specifies the lifetime of the environment. When an environment expires, GitLab automatically stops it.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : A period of time written in natural language. For example, these are all equivalent:

Example of environment:auto_stop_in :

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    auto_stop_in: 1 day

When the environment for review_app is created, the environment's lifetime is set to 1 day . Every time the review app is deployed, that lifetime is also reset to 1 day .

Related topics :

Introduced in GitLab 12.6.

Use the kubernetes keyword to configure deployments to a Kubernetes cluster that is associated with your project.

Keyword type : Job keyword. You can use it only as part of a job.

Example of environment:kubernetes :

deploy:
  stage: deploy
  script: make deploy-app
  environment:
    name: production
    kubernetes:
      namespace: production

This configuration sets up the deploy job to deploy to the production environment, using the production Kubernetes namespace .

Additional details :

Related topics :

Introduced in GitLab 13.10.

Use the deployment_tier keyword to specify the tier of the deployment environment.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : One of the following:

Example of environment:deployment_tier :

deploy:
  script: echo
  environment:
    name: customer-portal
    deployment_tier: production

Additional details :

Related topics :

Use CI/CD variables to dynamically name environments.

For example:

deploy as review app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com/

The deploy as review app job is marked as a deployment to dynamically create the review/$CI_COMMIT_REF_SLUG environment. $CI_COMMIT_REF_SLUG is a CI/CD variable set by the runner. The $CI_ENVIRONMENT_SLUG variable is based on the environment name, but suitable for inclusion in URLs. If the deploy as review app job runs in a branch named pow , this environment would be accessible with a URL like https://review-pow.example.com/ .

The common use case is to create dynamic environments for branches and use them as Review Apps. You can see an example that uses Review Apps at https://gitlab.com/gitlab-examples/review-apps-nginx/ .

Use extends to reuse configuration sections. It's an alternative to YAML anchors and is a little more flexible and readable.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of extends :

.tests:
  script: rake test
  stage: test
  only:
    refs:
      - branches
rspec:
  extends: .tests
  script: rake rspec
  only:
    variables:
      - $RSPEC

In this example, the rspec job uses the configuration from the .tests template job. When creating the pipeline, GitLab:

The result is this rspec job:

rspec:
  script: rake rspec
  stage: test
  only:
    refs:
      - branches
    variables:
      - $RSPEC

Additional details :

Related topics :

Use hooks to specify lists of commands to execute on the runner at certain stages of job execution, like before retrieving the Git repository.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Use hooks:pre_get_sources_script to specify a list of commands to execute on the runner before retrieving the Git repository and any submodules. You can use it to adjust the Git client configuration first, for example.

Related topics :

Example of hooks:pre_get_sources_script :

job1:
  hooks:
    pre_get_sources_script:
      - echo 'hello job1 pre_get_sources_script'
  script: echo 'hello job1 script'

Introduced in GitLab 15.7.

Use id_tokens to create JSON web tokens (JWT) to authenticate with third party services. All JWTs created this way support OIDC authentication. The required aud sub-keyword is used to configure the aud claim for the JWT.

Possible inputs :

Example of id_tokens :

job_with_id_tokens:
  id_tokens:
    ID_TOKEN_1:
      aud: https://gitlab.com
    ID_TOKEN_2:
      aud:
        - https://gcp.com
        - https://aws.com
    SIGSTORE_ID_TOKEN:
      aud: sigstore
  script:
    - command_to_authenticate_with_gitlab $ID_TOKEN_1
    - command_to_authenticate_with_aws $ID_TOKEN_2

Related topics :

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs : The name of the image, including the registry path if needed, in one of these formats:

CI/CD variables are supported .

Example of image :

default:
  image: ruby:3.0
rspec:
  script: bundle exec rspec
rspec 2.7:
  image: registry.example.com/my-group/my-project/ruby:2.7
  script: bundle exec rspec

In this example, the ruby:3.0 image is the default for all jobs in the pipeline. The rspec 2.7 job does not use the default, because it overrides the default with a job-specific image section.

Related topics :

The name of the Docker image that the job runs in. Similar to image used by itself.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs : The name of the image, including the registry path if needed, in one of these formats:

Example of image:name :

image:
  name: "registry.example.com/my/image:latest"

Related topics :

When the Docker container is created, the entrypoint is translated to the Docker --entrypoint option. The syntax is similar to the Dockerfile ENTRYPOINT directive , where each shell token is a separate string in the array.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of image:entrypoint :

image:
  name: super/sql:experimental
  entrypoint: [""]

Related topics :

The pull policy that the runner uses to fetch the Docker image.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Examples of image:pull_policy :

job1:
  script: echo "A single pull policy."
  image:
    name: ruby:3.0
    pull_policy: if-not-present
job2:
  script: echo "Multiple pull policies."
  image:
    name: ruby:3.0
    pull_policy: [always, if-not-present]

Additional details :

Related topics :

Introduced in GitLab 12.9.

Use inherit to control inheritance of default keywords and variables .

Use inherit:default to control the inheritance of default keywords .

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of inherit:default :

default:
  retry: 2
  image: ruby:3.0
  interruptible: true
job1:
  script: echo "This job does not inherit any default keywords."
  inherit:
    default: false
job2:
  script: echo "This job inherits only the two listed default keywords. It does not inherit 'interruptible'."
  inherit:
    default:
      - retry
      - image

Additional details :

Example of inherit:variables :

variables:
  VARIABLE1: "This is variable 1"
  VARIABLE2: "This is variable 2"
  VARIABLE3: "This is variable 3"
job1:
  script: echo "This job does not inherit any global variables."
  inherit:
    variables: false
job2:
  script: echo "This job inherits only the two listed global variables. It does not inherit 'VARIABLE3'."
  inherit:
    variables:
      - VARIABLE1
      - VARIABLE2

Additional details :

Example of interruptible :

stages:
  - stage1
  - stage2
  - stage3
step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true
step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."
step-3:
  stage: stage3
  script:
    - echo "Because step-2 can not be canceled, this step can never be canceled, even though it's set as interruptible."
  interruptible: true

In this example, a new pipeline causes a running pipeline to be:

Additional details :

Use needs to execute jobs out-of-order. Relationships between jobs that use needs can be visualized as a directed acyclic graph .

You can ignore stage ordering and run some jobs without waiting for others to complete. Jobs in multiple stages can run concurrently.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of needs :

linux:build:
  stage: build
  script: echo "Building linux..."
mac:build:
  stage: build
  script: echo "Building mac..."
lint:
  stage: test
  needs: []
  script: echo "Linting..."
linux:rspec:
  stage: test
  needs: ["linux:build"]
  script: echo "Running rspec on linux..."
mac:rspec:
  stage: test
  needs: ["mac:build"]
  script: echo "Running rspec on mac..."
production:
  stage: deploy
  script: echo "Running production..."
  environment: production

This example creates four paths of execution:

Additional details :

Introduced in GitLab 12.6.

When a job uses needs , it no longer downloads all artifacts from previous stages by default, because jobs with needs can start before earlier stages complete. With needs you can only download artifacts from the jobs listed in the needs configuration.

Use artifacts: true (default) or artifacts: false to control when artifacts are downloaded in jobs that use needs .

Keyword type : Job keyword. You can use it only as part of a job. Must be used with needs:job .

Possible inputs :

Example of needs:artifacts :

test-job1:
  stage: test
  needs:
    - job: build_job1
      artifacts: true
test-job2:
  stage: test
  needs:
    - job: build_job2
      artifacts: false
test-job3:
  needs:
    - job: build_job1
      artifacts: true
    - job: build_job2
    - build_job3

In this example:

Additional details :

Introduced in GitLab 12.7.

Use needs:project to download artifacts from up to five jobs in other pipelines. The artifacts are downloaded from the latest successful specified job for the specified ref. To specify multiple jobs, add each as separate array items under the needs keyword.

If there is a pipeline running for the ref, a job with needs:project does not wait for the pipeline to complete. Instead, the artifacts are downloaded from the latest successful run of the specified job.

needs:project must be used with job , ref , and artifacts .

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Examples of needs:project :

build_job:
  stage: build
  script:
    - ls -lhR
  needs:
    - project: namespace/group/project-name
      job: build-1
      ref: main
      artifacts: true
    - project: namespace/group/project-name-2
      job: build-2
      ref: main
      artifacts: true

In this example, build_job downloads the artifacts from the latest successful build-1 and build-2 jobs on the main branches in the group/project-name and group/project-name-2 projects.

In GitLab 13.3 and later, you can use CI/CD variables in needs:project , for example:

build_job:
  stage: build
  script:
    - ls -lhR
  needs:
    - project: $CI_PROJECT_PATH
      job: $DEPENDENCY_JOB_NAME
      ref: $ARTIFACTS_DOWNLOAD_REF
      artifacts: true

Additional details :

Related topics :

Introduced in GitLab 13.7.

A child pipeline can download artifacts from a job in its parent pipeline or another child pipeline in the same parent-child pipeline hierarchy.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of needs:pipeline:job :

Parent pipeline ( .gitlab-ci.yml ):

create-artifact:
  stage: build
  script: echo "sample artifact" > artifact.txt
  artifacts:
    paths: [artifact.txt]
child-pipeline:
  stage: test
  trigger:
    include: child.yml
    strategy: depend
  variables:
    PARENT_PIPELINE_ID: $CI_PIPELINE_ID

In this example, the create-artifact job in the parent pipeline creates some artifacts. The child-pipeline job triggers a child pipeline, and passes the CI_PIPELINE_ID variable to the child pipeline as a new PARENT_PIPELINE_ID variable. The child pipeline can use that variable in needs:pipeline to download artifacts from the parent pipeline.

Additional details :

Jobs that use rules , only , or except and that are added with include might not always be added to a pipeline. GitLab checks the needs relationships before starting a pipeline:

Keyword type : Job keyword. You can use it only as part of a job.

Example of needs:optional :

build-job:
  stage: build
test-job1:
  stage: test
test-job2:
  stage: test
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
deploy-job:
  stage: deploy
  needs:
    - job: test-job2
      optional: true
    - job: test-job1
  environment: production
review-job:
  stage: deploy
  needs:
    - job: test-job2
      optional: true
  environment: review

In this example:

You can mirror the pipeline status from an upstream pipeline to a job by using the needs:pipeline keyword. The latest pipeline status from the default branch is replicated to the job.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of needs:pipeline :

upstream_status:
  stage: test
  needs:
    pipeline: other/project

Additional details :

Introduced in GitLab 16.3.

Jobs can use parallel:matrix to run a job multiple times in parallel in a single pipeline, but with different variable values for each instance of the job.

Use needs:parallel:matrix to execute jobs out-of-order depending on parallelized jobs.

Keyword type : Job keyword. You can use it only as part of a job. Must be used with needs:job .

Possible inputs : An array of hashes of variables:

Example of needs:parallel:matrix :

linux:build:
  stage: build
  script: echo "Building linux..."
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2
linux:rspec:
  stage: test
  needs:
    - job: linux:build
      parallel:
        matrix:
          - PROVIDER: aws
          - STACK: app1
  script: echo "Running rspec on linux..."

The above example generates the following jobs:

linux:build: [aws, monitoring]
linux:build: [aws, app1]
linux:build: [aws, app2]
linux:rspec

The linux:rspec job runs as soon as the linux:build: [aws, app1] job finishes.

Related topics :

NOTE: only and except are not being actively developed. rules is the preferred keyword to control when to add jobs to pipelines.

You can use only and except to control when to add jobs to pipelines.

See specify when jobs run with only and except for more details and examples.

only:refs and except:refs are not being actively developed. rules:if is the preferred keyword when using refs, regular expressions, or variables to control when to add jobs to pipelines.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : An array including any number of:

Branch names, for example main or my-feature-branch .

Regular expressions that match against branch names, for example /^feature-.*/ .

The following keywords:

Scheduled pipelines run on specific branches, so jobs configured with only: branches run on scheduled pipelines too. Add except: schedules to prevent jobs with only: branches from running on scheduled pipelines.

only or except used without any other keywords are equivalent to only: refs or except: refs . For example, the following two jobs configurations have the same behavior:

job1:
  script: echo
  only:
    - branches
job2:
  script: echo
  only:
    refs:
      - branches

If a job does not use only , except , or rules , then only is set to branches and tags by default.

For example, job1 and job2 are equivalent:

job1:
  script: echo "test"
job2:
  script: echo "test"
  only:
    - branches
    - tags

Use the only:variables or except:variables keywords to control when to add jobs to a pipeline, based on the status of CI/CD variables .

only:variables and except:variables are not being actively developed. rules:if is the preferred keyword when using refs, regular expressions, or variables to control when to add jobs to pipelines.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of only:variables :

deploy:
  script: cap staging deploy
  only:
    variables:
      - $RELEASE == "staging"
      - $STAGING

Related topics :

only:changes and except:changes are not being actively developed. rules:changes is the preferred keyword when using changed files to control when to add jobs to pipelines.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : An array including any number of:

Example of only:changes :

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  only:
    refs:
      - branches
    changes:
      - Dockerfile
      - docker/scripts/*
      - dockerfiles/**/*
      - more_scripts/*.{rb,py,sh}
      - "**/*.json"

Additional details :

Related topics :

only:refs and except:refs are not being actively developed. Use rules:if with the CI_KUBERNETES_ACTIVE predefined CI/CD variable to control if jobs are added to the pipeline when the Kubernetes service is active in the project.

Keyword type : Job-specific. You can use it only as part of a job.

Possible inputs :

Example of only:kubernetes :

deploy:
  only:
    kubernetes: active

In this example, the deploy job runs only when the Kubernetes service is active in the project.

Use pages to define a GitLab Pages job that uploads static content to GitLab. The content is then published as a website.

You must:

Keyword type : Job name.

Example of pages :

pages:
  stage: deploy
  script:
    - mv my-html-content public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production

This example moves all files from a my-html-content/ directory to the public/ directory. This directory is exported as an artifact and published with GitLab Pages.

Introduced in GitLab 16.1.

Use publish to configure the content directory of a pages job .

Keyword type : Job keyword. You can use it only as part of a pages job.

Possible inputs : A path to a directory containing the Pages content.

Example of publish :

pages:
  stage: deploy
  script:
    - npx @11ty/eleventy --input=path/to/eleventy/root --output=dist
  artifacts:
    paths:
      - dist
  publish: dist
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production

This example uses Eleventy to generate a static website and output the generated HTML files into a the dist/ directory. This directory is exported as an artifact and published with GitLab Pages.

Introduced in GitLab 15.9, the maximum value for parallel is increased from 50 to 200.

Use parallel to run a job multiple times in parallel in a single pipeline.

Multiple runners must exist, or a single runner must be configured to run multiple jobs concurrently.

Parallel jobs are named sequentially from job_name 1/N to job_name N/N .

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of parallel :

test:
  script: rspec
  parallel: 5

This example creates 5 jobs that run in parallel, named test 1/5 to test 5/5 .

Additional details :

Related topics :

Use parallel:matrix to run a job multiple times in parallel in a single pipeline, but with different variable values for each instance of the job.

Multiple runners must exist, or a single runner must be configured to run multiple jobs concurrently.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : An array of hashes of variables:

Example of parallel:matrix :

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2
      - PROVIDER: ovh
        STACK: [monitoring, backup, app]
      - PROVIDER: [gcp, vultr]
        STACK: [data, processing]
  environment: $PROVIDER/$STACK

The example generates 10 parallel deploystacks jobs, each with different values for PROVIDER and STACK :

deploystacks: [aws, monitoring]
deploystacks: [aws, app1]
deploystacks: [aws, app2]
deploystacks: [ovh, monitoring]
deploystacks: [ovh, backup]
deploystacks: [ovh, app]
deploystacks: [gcp, data]
deploystacks: [gcp, processing]
deploystacks: [vultr, data]
deploystacks: [vultr, processing]

Additional details :

Related topics :

Introduced in GitLab 13.2.

Use release to create a release .

The release job must have access to the release-cli , which must be in the $PATH .

If you use the Docker executor , you can use this image from the GitLab Container Registry: registry.gitlab.com/gitlab-org/release-cli:latest

If you use the Shell executor or similar, install release-cli on the server where the runner is registered.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : The release subkeys:

Example of release keyword :

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
  script:
    - echo "Running the release job."
  release:
    tag_name: $CI_COMMIT_TAG
    name: 'Release $CI_COMMIT_TAG'
    description: 'Release created using the release-cli.'

This example creates a release:

Additional details :

All release jobs, except trigger jobs, must include the script keyword. A release job can use the output from script commands. If you don't need the script, you can use a placeholder:

script:
  - echo "release job"

An issue exists to remove this requirement.

The release section executes after the script keyword and before the after_script .

A release is created only if the job's main script succeeds.

If the release already exists, it is not updated and the job with the release keyword fails.

Related topics :

CI/CD variables are supported .

Example of release:tag_name :

To create a release when a new tag is added to the project:

job:
  script: echo "Running the release job for the new tag."
  release:
    tag_name: $CI_COMMIT_TAG
    description: 'Release description'
  rules:
    - if: $CI_COMMIT_TAG

To create a release and a new tag at the same time, your rules should not configure the job to run only for new tags. A semantic versioning example:

job:
  script: echo "Running the release job and creating a new tag."
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: 'Release description'
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

Introduced in GitLab 15.3. Supported by release-cli v0.12.0 or later.

If the tag does not exist, the newly created tag is annotated with the message specified by tag_message . If omitted, a lightweight tag is created.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of release:tag_message :

  release_job:
    stage: release
    release:
      tag_name: $CI_COMMIT_TAG
      description: 'Release description'
      tag_message: 'Annotated tag message'

  release_job:
    stage: release
    release:
      name: 'Release $CI_COMMIT_TAG'

Example of release:description :

job:
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: './path/to/CHANGELOG.md'

Additional details :

released_at: '2021-03-15T08:00:00Z'

Introduced in GitLab 13.12.

Use release:assets:links to include asset links in the release.

Requires release-cli version v0.4.0 or later.

Example of release:assets:links :

assets:
  links:
    - name: 'asset1'
      url: 'https://example.com/assets/1'
    - name: 'asset2'
      url: 'https://example.com/assets/2'
      filepath: '/pretty/url/1' # optional
      link_type: 'other' # optional

Introduced in GitLab 12.7.

Use resource_group to create a resource group that ensures a job is mutually exclusive across different pipelines for the same project.

For example, if multiple jobs that belong to the same resource group are queued simultaneously, only one of the jobs starts. The other jobs wait until the resource_group is free.

Resource groups behave similar to semaphores in other programming languages.

You can define multiple resource groups per environment. For example, when deploying to physical devices, you might have multiple physical devices. Each device can be deployed to, but only one deployment can occur per device at any given time.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of resource_group :

deploy-to-production:
  script: deploy
  resource_group: production

In this example, two deploy-to-production jobs in two separate pipelines can never run at the same time. As a result, you can ensure that concurrent deployments never happen to the production environment.

Related topics :

By default, all failure types cause the job to be retried. Use retry:when to select which failures to retry on.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of retry :

test:
  script: rspec
  retry: 2

Use retry:when with retry:max to retry jobs for only specific failure cases. retry:max is the maximum number of retries, like retry , and can be 0 , 1 , or 2 .

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of retry:when (single failure type):

test:
  script: rspec
  retry:
    max: 2
    when: runner_system_failure

If there is a failure other than a runner system failure, the job is not retried.

Example of retry:when (array of failure types):

test:
  script: rspec
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure

Related topics :

You can specify the number of retry attempts for certain stages of job execution using variables.

Introduced in GitLab 12.3.

Use rules to include or exclude jobs in pipelines.

Rules are evaluated when the pipeline is created, and evaluated in order until the first match. When a match is found, the job is either included or excluded from the pipeline, depending on the configuration.

You cannot use dotenv variables created in job scripts in rules, because rules are evaluated before any jobs run.

rules replaces only/except and they can't be used together in the same job. If you configure one job to use both keywords, the GitLab returns a key may not be used with rules error.

rules accepts an array of rules defined with:

You can combine multiple keywords together for complex rules .

The job is added to the pipeline:

The job is not added to the pipeline:

You can use !reference tags to reuse rules configuration in different jobs.

if clauses are evaluated based on the values of CI/CD variables or predefined CI/CD variables , with some exceptions .

Keyword type : Job-specific and pipeline-specific. You can use it as part of a job to configure the job behavior, or with workflow to configure the pipeline behavior.

Possible inputs :

Example of rules:if :

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME != $CI_DEFAULT_BRANCH
      when: never
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/
      when: manual
      allow_failure: true
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME

Additional details :

Related topics :

Example of rules:changes :

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - Dockerfile
      when: manual
      allow_failure: true

Additional details :

Related topics :

Introduced in GitLab 15.2.

Use rules:changes to specify that a job only be added to a pipeline when specific files are changed, and use rules:changes:paths to specify the files.

rules:changes:paths is the same as using rules:changes without any subkeys. All additional details and related topics are the same.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of rules:changes:paths :

docker-build-1:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - Dockerfile
docker-build-2:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        paths:
          - Dockerfile

In this example, both jobs have the same behavior.

Use rules:changes:compare_to to specify which ref to compare against for changes to the files listed under rules:changes:paths .

Keyword type : Job keyword. You can use it only as part of a job, and it must be combined with rules:changes:paths .

Possible inputs :

Example of rules:changes:compare_to :

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        paths:
          - Dockerfile
        compare_to: 'refs/heads/branch1'

In this example, the docker build job is only included when the Dockerfile has changed relative to refs/heads/branch1 and the pipeline source is a merge request event.

Example of rules:exists :

job:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - exists:
        - Dockerfile

job runs if a Dockerfile exists anywhere in the repository.

Additional details :

Introduced in GitLab 12.8.

Use allow_failure: true in rules to allow a job to fail without stopping the pipeline.

You can also use allow_failure: true with a manual job. The pipeline continues running without waiting for the result of the manual job. allow_failure: false combined with when: manual in rules causes the pipeline to wait for the manual job to run before continuing.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of rules:allow_failure :

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
      when: manual
      allow_failure: true

If the rule matches, then the job is a manual job with allow_failure: true .

Additional details :

Use needs in rules to update a job's needs for specific conditions. When a condition matches a rule, the job's needs configuration is completely replaced with the needs in the rule.

Keyword type : Job-specific. You can use it only as part of a job.

Possible inputs :

Example of rules:needs :

build-dev:
  stage: build
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
  script: echo "Feature branch, so building dev version..."
build-prod:
  stage: build
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script: echo "Default branch, so building prod version..."
specs:
  stage: test
  needs: ['build-dev']
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      needs: ['build-prod']
    - when: on_success # Run the job in other cases
  script: echo "Running dev specs by default, or prod specs when default branch..."

In this example:

Additional details :

Use variables in rules to define variables for specific conditions.

Keyword type : Job-specific. You can use it only as part of a job.

Possible inputs :

Example of rules:variables :

job:
  variables:
    DEPLOY_VARIABLE: "default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                              # Override DEPLOY_VARIABLE defined
        DEPLOY_VARIABLE: "deploy-production"  # at the job level.
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # Define a new variable.
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

All jobs except trigger jobs require a script keyword.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : An array including:

CI/CD variables are supported .

Example of script :

job1:
  script: "bundle exec rspec"
job2:
  script:
    - uname -a
    - bundle exec rspec

Additional details :

Related topics :

Introduced in GitLab 13.4.

Use secrets to specify CI/CD secrets to:

Introduced in GitLab 13.4 and GitLab Runner 13.4.

Use secrets:vault to specify secrets provided by a HashiCorp Vault .

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of secrets:vault :

To specify all details explicitly and use the KV-V2 secrets engine:

job:
  secrets:
    DATABASE_PASSWORD:  # Store the path to the secret in this CI/CD variable
      vault:  # Translates to secret: `ops/data/production/db`, field: `password`
        engine:
          name: kv-v2
          path: ops
        path: production/db
        field: password

You can shorten this syntax. With the short syntax, engine:name and engine:path both default to kv-v2 :

job:
  secrets:
    DATABASE_PASSWORD:  # Store the path to the secret in this CI/CD variable
      vault: production/db/password  # Translates to secret: `kv-v2/data/production/db`, field: `password`

To specify a custom secrets engine path in the short syntax, add a suffix that starts with @ :

job:
  secrets:
    DATABASE_PASSWORD:  # Store the path to the secret in this CI/CD variable
      vault: production/db/password@ops  # Translates to secret: `ops/data/production/db`, field: `password`

Introduced in GitLab 16.3 and GitLab Runner 16.3.

Use secrets:azure_key_vault to specify secrets provided by a Azure Key Vault .

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of secrets:azure_key_vault :

job:
  secrets:
    DATABASE_PASSWORD:
      azure_key_vault:
        name: 'test'
        version: 'test'

Related topics :

Introduced in GitLab 14.1 and GitLab Runner 14.1.

Use secrets:file to configure the secret to be stored as either a file or variable type CI/CD variable

By default, the secret is passed to the job as a file type CI/CD variable. The value of the secret is stored in the file and the variable contains the path to the file.

If your software can't use file type CI/CD variables, set file: false to store the secret value directly in the variable.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of secrets:file :

job:
  secrets:
    DATABASE_PASSWORD:
      vault: production/db/password@ops
      file: false

Additional details :

Introduced in GitLab 15.8.

Use secrets:token to explicitly select a token to use when authenticating with Vault by referencing the token's CI/CD variable.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of secrets:token :

job:
  id_tokens:
    AWS_TOKEN:
      aud: https://aws.example.com
    VAULT_TOKEN:
      aud: https://vault.example.com
  secrets:
    DB_PASSWORD:
      vault: gitlab/production/db
      token: $VAULT_TOKEN

Additional details :

Use services to specify any additional Docker images that your scripts require to run successfully. The services image is linked to the image specified in the image keyword.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs : The name of the services image, including the registry path if needed, in one of these formats:

CI/CD variables are supported , but not for alias .

Example of services :

default:
  image:
    name: ruby:2.6
    entrypoint: ["/bin/bash"]
  services:
    - name: my-postgres:11.7
      alias: db-postgres
      entrypoint: ["/usr/local/bin/db-postgres"]
      command: ["start"]
  before_script:
    - bundle install
test:
  script:
    - bundle exec rake spec

In this example, GitLab launches two containers for the job:

Related topics :

The pull policy that the runner uses to fetch the Docker image.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Examples of service:pull_policy :

job1:
  script: echo "A single pull policy."
  services:
    - name: postgres:11.6
      pull_policy: if-not-present
job2:
  script: echo "Multiple pull policies."
  services:
    - name: postgres:11.6
      pull_policy: [always, if-not-present]

Additional details :

Related topics :

Use stage to define which stage a job runs in. Jobs in the same stage can execute in parallel (see Additional details ).

If stage is not defined, the job uses the test stage by default.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs : A string, which can be a:

Example of stage :

stages:
  - build
  - test
  - deploy
job1:
  stage: build
  script:
    - echo "This job compiles code."
job2:
  stage: test
  script:
    - echo "This job tests the compiled code. It runs when the build stage completes."
job3:
  script:
    - echo "This job also runs in the test stage".
job4:
  stage: deploy
  script:
    - echo "This job deploys the code. It runs when the test stage completes."
  environment: production

Additional details :

Introduced in GitLab 12.4.

Use the .pre stage to make a job run at the start of a pipeline. .pre is always the first stage in a pipeline. User-defined stages execute after .pre . You do not have to define .pre in stages .

If a pipeline contains only jobs in the .pre or .post stages, it does not run. There must be at least one other job in a different stage.

Keyword type : You can only use it with a job's stage keyword.

Example of stage: .pre :

stages:
  - build
  - test
job1:
  stage: build
  script:
    - echo "This job runs in the build stage."
first-job:
  stage: .pre
  script:
    - echo "This job runs in the .pre stage, before all other stages."
job2:
  stage: test
  script:
    - echo "This job runs in the test stage."

Introduced in GitLab 12.4.

Use the .post stage to make a job run at the end of a pipeline. .post is always the last stage in a pipeline. User-defined stages execute before .post . You do not have to define .post in stages .

If a pipeline contains only jobs in the .pre or .post stages, it does not run. There must be at least one other job in a different stage.

Keyword type : You can only use it with a job's stage keyword.

Example of stage: .post :

stages:
  - build
  - test
job1:
  stage: build
  script:
    - echo "This job runs in the build stage."
last-job:
  stage: .post
  script:
    - echo "This job runs in the .post stage, after all other stages."
job2:
  stage: test
  script:
    - echo "This job runs in the test stage."

Additional details:

Use tags to select a specific runner from the list of all runners that are available for the project.

When you register a runner, you can specify the runner's tags, for example ruby , postgres , or development . To pick up and run a job, a runner must be assigned every tag listed in the job.

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs :

Example of tags :

job:
  tags:
    - ruby
    - postgres

In this example, only runners with both the ruby and postgres tags can run the job.

Additional details :

Related topics :

Introduced in GitLab 12.3.

Use timeout to configure a timeout for a specific job. If the job runs for longer than the timeout, the job fails.

The job-level timeout can be longer than the project-level timeout . but can't be longer than the runner's timeout .

Keyword type : Job keyword. You can use it only as part of a job or in the default section .

Possible inputs : A period of time written in natural language. For example, these are all equivalent:

Example of timeout :

build:
  script: build.sh
  timeout: 3 hours 30 minutes
test:
  script: rspec
  timeout: 3h 30m

Use trigger to declare that a job is a "trigger job" which starts a downstream pipeline that is either:

Trigger jobs can use only a limited set of GitLab CI/CD configuration keywords. The keywords available for use in trigger jobs are:

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of trigger :

trigger-multi-project-pipeline:
  trigger: my-group/my-project

Additional details :

Related topics :

Use trigger:include to declare that a job is a "trigger job" which starts a child pipeline .

Use trigger:include:artifact to trigger a dynamic child pipeline .

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of trigger:include :

trigger-child-pipeline:
  trigger:
    include: path/to/child-pipeline.gitlab-ci.yml

Related topics :

Use trigger:project to declare that a job is a "trigger job" which starts a multi-project pipeline .

By default, the multi-project pipeline triggers for the default branch. Use trigger:branch to specify a different branch.

Keyword type : Job keyword. You can use it only as part of a job.

Possible inputs :

Example of trigger:project :

trigger-multi-project-pipeline:
  trigger:
    project: my-group/my-project

Example of trigger:project for a different branch :

trigger-multi-project-pipeline:
  trigger:
    project: my-group/my-project
    branch: development

Related topics :

trigger_job:
  trigger:
    include: path/to/child-pipeline.yml
    strategy: depend

Use trigger:forward to specify what to forward to the downstream pipeline. You can control what is forwarded to both parent-child pipelines and multi-project pipelines .

Possible inputs :

Example of trigger:forward :

Run this pipeline manually , with the CI/CD variable MYVAR = my value :

variables: # default variables for each job
  VAR: value
# Default behavior:
# - VAR is passed to the child
# - MYVAR is not passed to the child
child1:
  trigger:
    include: .child-pipeline.yml
# Forward pipeline variables:
# - VAR is passed to the child
# - MYVAR is passed to the child
child2:
  trigger:
    include: .child-pipeline.yml
    forward:
      pipeline_variables: true
# Do not forward YAML variables:
# - VAR is not passed to the child
# - MYVAR is not passed to the child
child3:
  trigger:
    include: .child-pipeline.yml
    forward:
      yaml_variables: false

Use variables to define CI/CD variables for jobs.

Keyword type : Global and job keyword. You can use it at the global level, and also at the job level.

If you define variables as a global keyword , it behaves like default variables for all jobs. Each variable is copied to every job configuration when the pipeline is created. If the job already has that variable defined, the job-level variable takes precedence .

Variables defined at the global-level cannot be used as inputs for other global keywords like include . These variables can only be used at the job-level, in script , before_script , and after_script sections, as well as inputs in some job keywords like rules .

Possible inputs : Variable name and value pairs:

CI/CD variables are supported .

Examples of variables :

variables:
  DEPLOY_SITE: "https://example.com/"
deploy_job:
  stage: deploy
  script:
    - deploy-script --url $DEPLOY_SITE --path "/"
  environment: production
deploy_review_job:
  stage: deploy
  variables:
    REVIEW_PATH: "/review"
  script:
    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
  environment: production

Additional details :

Related topics :

Introduced in GitLab 13.7.

Use the description keyword to define a description for a pipeline-level (global) variable. The description displays with the prefilled variable name when running a pipeline manually .

Keyword type : Global keyword. You cannot use it for job-level variables.

Possible inputs :

Example of variables:description :

variables:
  DEPLOY_NOTE:
    description: "The deployment note. Explain the reason for this deployment."

Additional details :

Introduced in GitLab 13.7.

Use the value keyword to define a pipeline-level (global) variable's value. When used with variables: description , the variable value is prefilled when running a pipeline manually .

Keyword type : Global keyword. You cannot use it for job-level variables.

Possible inputs :

Example of variables:value :

variables:
  DEPLOY_ENVIRONMENT:
    value: "staging"
    description: "The deployment target. Change this variable to 'canary' or 'production' if needed."

Additional details :

Introduced in GitLab 15.7.

Use variables:options to define an array of values that are selectable in the UI when running a pipeline manually .

Must be used with variables: value , and the string defined for value :