🦊 Reading CI Pipeline YAML
5 exercises — read a real GitLab CI pipeline. Understand stages, before_script, artifacts, cache and rules/branch filters, and how the jobs fit together.
CI pipeline quick reference
stages→ ordered phases; the next runs only if the current passesbefore_script→ runs at the start of every jobartifacts= outputs to keep/pass on ·cache= inputs to reuse for speedrules/only/except→ control when a job runs$VAR/${VAR}→ a predefined or custom CI variable
0 / 5 completed
1 / 5
.gitlab-ci.yml
stages:
- build
- test
- deploy
default:
image: node:20
before_script:
- npm ci
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
build-job:
stage: build
script:
- npm run build
artifacts:
paths:
- dist/
expire_in: 1 week
test-job:
stage: test
script:
- npm test
deploy-job:
stage: deploy
script:
- ./deploy.sh
rules:
- if: '$CI_COMMIT_BRANCH == "main"'What does the top-level
stages list (build, test, deploy) define?stages defines the ordered phases of the pipeline.Jobs are grouped into stages, and the stages run in sequence: all
build jobs first, then all test jobs, then all deploy jobs. Each job declares which stage it belongs to via its own stage: key.- Jobs within the same stage run in parallel.
- The next stage only starts if every job in the current stage succeeds.
- So a failing
test-jobstopsdeploy-jobfrom ever running.
Don't confuse: stages order groups of jobs; the
image: key chooses the container; branch control is done with rules/only.Collocations: "the build stage", "pipeline stages", "run in sequence", "the stage failed", "jobs in the same stage run in parallel".