Choose when to run jobs

Use rules to include or exclude jobs in pipelines.

Rules are 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. See the rules reference for more details.

Future keyword improvements are being discussed in our rules, where anyone can add suggestions or requests.

rules examples

The following example uses if to define that the job runs in only two specific cases:

job:
  script: echo "Hello, Rules!"
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: manual
      allow_failure: true
    - if: '$CI_PIPELINE_SOURCE == "schedule"'

• If the pipeline is for a merge request, the first rule matches, and the job is added to the merge request pipeline with attributes of:
  • when: manual (manual job)
  • allow_failure: true (the pipeline continues running even if the manual job is not run)
• If the pipeline is not for a merge request, the first rule doesn’t match, and the second rule is evaluated.
• If the pipeline is a scheduled pipeline, the second rule matches, and the job is added to the scheduled pipeline. No attributes were defined, so it is added with:
  • when: on_success (default)
  • allow_failure: false (default)
• In all other cases, no rules match, so the job is not added to any other pipeline.

Alternatively, you can define a set of rules to exclude jobs in a few cases, but run them in all other cases:

job:
  script: echo "Hello, Rules!"
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: never
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
      when: never
    - when: on_success

• If the pipeline is for a merge request, the job is not added to the pipeline.
• If the pipeline is a scheduled pipeline, the job is not added to the pipeline.
• In all other cases, the job is added to the pipeline, with when: on_success.

Run jobs for scheduled pipelines

To configure a job to be executed only when the pipeline has been scheduled, use the rules keyword.

In this example, make world runs in scheduled pipelines, and make build runs in branch and tag pipelines:

job:on-schedule:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
  script:
    - make world

job:
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
  script:
    - make build

Complex rules

You can use all rules keywords, like if, changes, and exists, in the same rule. The rule evaluates to true only when all included keywords evaluate to true.

For example:

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: '$VAR == "string value"'
      changes:  # Include the job and set to when:manual if any of the follow paths match a modified file.
        - Dockerfile
        - docker/scripts/*
      when: manual
      allow_failure: true

If the Dockerfile file or any file in /docker/scripts has changed and $VAR == “string value”, then the job runs manually and is allowed to fail.

You can use parentheses with && and || to build more complicated variable expressions.

job1:
  script:
    - echo This rule uses parentheses.
  rules:
    - if: ($CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE

Use !reference tags to reuse rules in different jobs. You can combine !reference rules with regular job-defined rules:

.default_rules:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

job1:
  rules:
    - !reference [.default_rules, rules]
  script:
    - echo "This job runs for the default branch, but not schedules."

job2:
  rules:
    - !reference [.default_rules, rules]
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - echo "This job runs for the default branch, but not schedules."
    - echo "It also runs for merge requests."

Specify when jobs run with only and except

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

• Use only to define when a job runs.
• Use except to define when a job does not run.

only:refs / except:refs examples

only or except used without refs is the same as only:refs / except/refs

In the following example, job runs only for:

• Git tags
• Triggers
• Scheduled pipelines

job:
  # use special keywords
  only:
    - tags
    - triggers
    - schedules

To execute jobs only for the parent repository and not forks:

job:
  only:
    - branches@gitlab-org/gitlab
  except:
    - main@gitlab-org/gitlab
    - /^release/.*$/@gitlab-org/gitlab

This example runs job for all branches on gitlab-org/gitlab, except main and branches that start with release/.

only: variables / except: variables examples

You can use except:variables to exclude jobs based on a commit message:

end-to-end:
  script: rake test:end-to-end
  except:
    variables:
      - $CI_COMMIT_MESSAGE =~ /skip-end-to-end-tests/

You can use parentheses with && and || to build more complicated variable expressions:

job1:
  script:
    - echo This rule uses parentheses.
  only:
    variables:
      - ($CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE

When multiple entries are specified in only:variables, the job runs when at least one of them evaluates to true. You can use && in a single entry when multiple conditions must be satisfied at the same time.

only:changes / except:changes examples

You can skip a job if a change is detected in any file with a .md extension in the root directory of the repository:

build:
  script: npm run build
  except:
    changes:
      - "*.md"

If you change multiple files, but only one file ends in .md, the build job is still skipped. The job does not run for any of the files.

With some configurations that use changes, jobs or pipelines might run unexpectedly

Use only:changes with merge request pipelines

With merge request pipelines, it’s possible to define a job to be created based on files modified in a merge request.

Use this keyword with only: [merge_requests] so GitLab can find the correct base SHA of the source branch. File differences are correctly calculated from any further commits, and all changes in the merge requests are properly tested in pipelines.

For example:

docker build service one:
  script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
  only:
    refs:
      - merge_requests
    changes:
      - Dockerfile
      - service-one/**/*

In this scenario, if a merge request changes files in the service-one directory or the Dockerfile, GitLab creates the docker build service one job.

For example:

docker build service one:
  script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
  only:
    changes:
      - Dockerfile
      - service-one/**/*

In this example, the pipeline might fail because of changes to a file in service-one/**/*.

A later commit that doesn’t have changes in service-one/**/* but does have changes to the Dockerfile can pass. The job only tests the changes to the Dockerfile.

GitLab checks the most recent pipeline that passed. If the merge request is mergeable, it doesn’t matter that an earlier pipeline failed because of a change that has not been corrected.

When you use this configuration, ensure that the most recent pipeline properly corrects any failures from previous pipelines.

Combine multiple keywords with only or except

If you use multiple keywords with only or except, the keywords are evaluated as a single conjoined expression. That is:

• only includes the job if all of the keys have at least one condition that matches.
• except excludes the job if any of the keys have at least one condition that matches.

With only, individual keys are logically joined by an AND. A job is added to the pipeline if the following is true:

• (any listed refs are true) AND (any listed variables are true) AND (any listed changes are true) AND (any chosen Kubernetes status matches)

In the following example, the test job is only created when all of the following are true:

• The pipeline is scheduled or runs for main.
• The variables keyword matches.
• The kubernetes service is active on the project.

test:
  script: npm run test
  only:
    refs:
      - main
      - schedules
    variables:
      - $CI_COMMIT_MESSAGE =~ /run-end-to-end-tests/
    kubernetes: active

With except, individual keys are logically joined by an OR. A job is not added if the following is true:

• (any listed refs are true) OR (any listed variables are true) OR (any listed changes are true) OR (a chosen Kubernetes status matches)

In the following example, the test job is not created when any of the following are true:

• The pipeline runs for the main branch.
• There are changes to the README.md file in the root directory of the repository.

test:
  script: npm run test
  except:
    refs:
      - main
    changes:
      - "README.md"

Create a job that must be run manually

You can require that a job doesn’t run unless a user starts it. This is called a manual job. You might want to use a manual job for something like deploying to production.

To specify a job as manual, add when: manual to the job in the .gitlab-ci.yml file.

By default, manual jobs display as skipped when the pipeline starts.

You can use protected branches to more strictly protect manual deployments from being run by unauthorized users.

Types of manual jobs

Manual jobs can be either optional or blocking:

• Optional: The default setting for manual jobs.
  • They have allow_failure: true by default.
  • The status does not contribute to the overall pipeline status. A pipeline can succeed even if all of its manual jobs fail.
• Blocking: An optional setting for manual jobs.
  • Add allow_failure: false to the job configuration.
  • The pipeline stops at the stage where the job is defined. To let the pipeline continue running, run the manual job.
  • Merge requests in projects with merge when pipeline succeeds enabled can’t be merged with a blocked pipeline. Blocked pipelines show a status of blocked.

Run a manual job

To run a manual job, you must have permission to merge to the assigned branch.

To run a manual job:

1. Go to the pipeline, job, environment, or deployment view.
2. Next to the manual job, select Play ().

Protect manual jobs

Use protected environments to define a list of users authorized to run a manual job. You can authorize only the users associated with a protected environment to trigger manual jobs, which can:

• More precisely limit who can deploy to an environment.
• Block a pipeline until an approved user “approves” it.

To protect a manual job:

1. Add an environment to the job. For example:

   deploy_prod:
     stage: deploy
     script:
       - echo "Deploy to production server"
     environment:
       name: production
       url: https://example.com
     when: manual
     rules:
       - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
   

2. In the protected environments settings, select the environment (production in this example) and add the users, roles or groups that are authorized to trigger the manual job to the Allowed to Deploy list. Only those in this list can trigger this manual job, as well as GitLab administrators who are always able to use protected environments.

You can use protected environments with blocking manual jobs to have a list of users allowed to approve later pipeline stages. Add allow_failure: false to the protected manual job and the pipeline’s next stages only run after the manual job is triggered by authorized users.

Run a job after a delay

timed rollout 10%:
  stage: deploy
  script: echo 'Rolling out 10% ...'
  when: delayed
  start_in: 30 minutes

# Gemfile
source 'https://rubygems.org'

gem 'rspec'
gem 'semaphore_test_boosters'

test:
  parallel: 3
  script:
    - bundle
    - bundle exec rspec_booster --job $CI_NODE_INDEX/$CI_NODE_TOTAL

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: [aws, ovh, gcp, vultr]

deploystacks:
  stage: deploy
  trigger:
    include: path/to/child-pipeline.yml
  parallel:
    matrix:
      - PROVIDER: aws
        STACK: [monitoring, app1]
      - PROVIDER: ovh
        STACK: [monitoring, backup]
      - PROVIDER: [gcp, vultr]
        STACK: [data]

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

deploystacks:
  stage: deploy
  parallel:
    matrix:
      - PROVIDER: aws
        STACK: [monitoring, app1]
      - PROVIDER: gcp
        STACK: [data]
  tags:
    - ${PROVIDER}-${STACK}

<job_name> [<matrix argument 1>, <matrix argument 2>, ... <matrix argument N>]

ruby:
  image: ruby:${RUBY_VERSION}
  parallel:
    matrix:
      - RUBY_VERSION: ["2.5", "2.6", "2.7", "3.0", "3.1"]
        PROVIDER: [aws, gcp]
  script: bundle install

deploy:
  image: ruby:2.7
  stage: deploy
  dependencies:
    - "ruby: [2.7, aws]"
  script: echo hello

job1:
  script:
    - echo
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_PIPELINE_SOURCE == "schedule"
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never

job:
  # use regexp
  only:
    - /^issue-.*$/i
  # use special keyword
  except:
    - branches

job1:
  variables:
    VAR1: "variable1"
  script:
    - echo "Test variable comparison
  rules:
    - if: $VAR1 == "variable1"