GitLab CI Configuration Options: tags, allow_failure, when, manual, delayed, retry, timeout, and parallel

In GitLab CI you can select specific runners using tags, for example assigning ruby and postgres tags to a runner.

Jobs can be limited to runners with matching tags, such as an OS X runner ( osx) or a Windows runner ( windows).

The allow_failure keyword lets a job fail without blocking the pipeline; failed jobs are shown with an orange warning but the pipeline continues.

job1:
  stage: test
  script:
    - execute_script_that_will_fail
  allow_failure: true

The when keyword controls job execution timing: on_success (default) runs after all previous jobs succeed, on_failure runs when a previous job fails, always runs regardless, and manual requires manual triggering, often used for production deployments.

The delayed keyword schedules a job to run after a specified interval (e.g., 5 seconds, 30 minutes, 1 day).

The retry keyword defines how many times a failed job should be retried, with optional hash keys max and when to fine‑tune retry behavior for specific failure types.

unittest:
  stage: test
  retry: 2
  script:
    - ech "run test"

The timeout keyword sets a maximum execution time for a job, which can exceed the project‑level timeout but not the runner‑level limit.

build:
  script: build.sh
  timeout: 3 hours 30 minutes

test:
  script: rspec
  timeout: 3h 30m

Project‑wide pipeline timeout and runner‑specific timeout can be configured in the project settings under CI/CD → General pipelines.

The parallel keyword runs multiple instances of the same job concurrently (2‑50 instances), naming them sequentially.

codescan:
  stage: codescan
  tags:
    - build
  only:
    - master
  script:
    - echo "codescan"
    - sleep 5;
  parallel: 5