TopolearnEvery .gitlab-ci.yml is written in these terms, and they decide what runs in parallel and where.
A pipeline is one execution of your CI/CD configuration, created when you push, open a merge request, run a schedule or click Run pipeline. It is defined in .gitlab-ci.yml at the repository root.
A pipeline consists of jobs: named units of work, each with a script of shell commands. Jobs are grouped into stages that run in order: by default build, then test, then deploy, with hidden .pre and .post stages at the very start and end. All jobs in one stage run in parallel; the next stage starts only when every job of the previous stage has succeeded. A job without a stage goes into test.
Jobs are executed by runners: agents that poll GitLab for work. GitLab.com provides hosted runners; companies often register their own. Most runners use the Docker executor, so each job runs in a fresh container from the image you choose.
The pipeline graph, job logs, test reports and artifacts appear in the GitLab UI under Build, Pipelines. The pipeline status is attached to the commit and to merge requests, where it can be required to pass before merging.
Because each job starts in a clean container, jobs share nothing by default: files must be passed with artifacts or cache, which you will learn shortly.
Example
# .gitlab-ci.yml : three stages, four jobs
stages: [build, test, deploy]
build-app:
stage: build
script: echo "compiling"
unit-tests: # these two run in parallel
stage: test
script: echo "unit tests"
lint:
stage: test
script: echo "linting"
deploy-prod: # starts after both test jobs pass
stage: deploy
script: echo "deploying" Remember
- A pipeline has stages; a stage has jobs; runners execute jobs
- Jobs in a stage run in parallel; stages run in order
- Each job starts in a clean environment
Watch out for
- Assuming a file created in the build job is automatically present in the test job.