GitLab CI/CD Associate study materials
GitLab CI/CD Associate study resources

GitLab CI/CD Associate: Job Execution, Stages, and Pipeline Flow Control

GitLab CI/CD Associate · Work through your exam, one topic at a time.

All guide sections

Job Execution, Stages, and Pipeline Flow Control

This domain tests pipeline flow: the order stages and jobs execute, what happens when a job fails, and how rules, needs, and when reshape the default stage-by-stage progression.

Stages, jobs, and failure propagation

Jobs in the same stage run in parallel; stages run sequentially in the order declared. When a job fails (non-zero exit), the pipeline stops and later stages are not created - they appear as skipped, not failed. Exceptions: allow_failure: true does not block, and downstream jobs with when: always or when: on_failure still run. when accepts on_success (default), on_failure, always, manual, delayed, and never.

needs: builds a DAG and lets a job start as soon as its dependencies finish, ignoring stage order. needs: [] starts immediately. A job may only need jobs from the same or earlier stages.

Rules

rules is an ordered list evaluated top to bottom; the first match decides and the rest are ignored. Each rule can set if, changes, exists, when, allow_failure, and variables. A trailing - when: never is the idiomatic catch-all. workflow:rules does the same at pipeline level.

Worked example

deploy:
  stage: deploy
  script: ./deploy.sh
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual
      allow_failure: false
    - if: $CI_COMMIT_TAG
    - when: never

On the default branch the job is created as a blocking manual action: the pipeline stays blocked until someone clicks play, and it cannot succeed while the job is pending. On a tag it runs automatically. On a feature branch it is never created. The if clauses read predefined variables available at rule-evaluation time; variables declared in the same job's variables: block are not reliable there.

retry (maximum 2) reruns a failed job, timeout caps runtime, interruptible: true lets a newer pipeline cancel the job, and resource_group serialises jobs sharing a resource.

Traps

  • Using only/except and rules in the same job - invalid configuration.
  • Expecting a skipped stage to read as failed; it reads as skipped.
  • Forgetting that manual jobs default to allow_failure: true unless set false.
  • Using needs to reference a job that rules excluded - pipeline creation fails with "job not found".