Stages, jobs et artefacts
La granularite d'un pipeline GitLab repose sur trois concepts imbriques : les stages (phases sequentielles), les jobs (unites d'execution dans un stage) et les artefacts (fichiers produits et transmis entre jobs).
Stages
Les stages sont declares dans stages: au niveau global et definissent l'ordre d'execution. Les stages courants en CD :
stages:
- .pre # stage special, execute toujours en premier
- lint
- build
- test
- security
- package
- deploy
- .post # stage special, execute toujours en dernierLes stages .pre et .post sont integres a GitLab et ne necessitent pas d'etre declares. Ils servent aux taches de setup et de cleanup.
Jobs
Un job a un nom unique dans le fichier. Il peut etre etendu (extends), inclus depuis un fichier externe, ou defini comme template (nom prefixe par un point : .template-job est ignore par le scheduler).
.base-python:
image: python:3.12-slim
before_script:
- pip install -r requirements.txt
lint:
extends: .base-python
script:
- flake8 src/
unit-test:
extends: .base-python
script:
- pytest tests/unit/Artefacts
Les artefacts sont des fichiers produits par un job et conserves par GitLab. Ils peuvent etre telecharges depuis l'interface, recuperes par les jobs suivants, ou utilises dans les pages GitLab.
build:
script:
- make build
artifacts:
paths:
- dist/
expire_in: 1 week
when: on_successLes rapports de test, de couverture et de securite sont des artefacts speciaux avec des types declares (reports:). GitLab les parse et les affiche dans l'interface MR :
artifacts:
reports:
junit: report.xml
coverage_report:
coverage_format: cobertura
path: coverage.xml
sast: gl-sast-report.jsonTransmission entre jobs
Un job recupere les artefacts de ses dependances automatiquement si needs est utilise avec artifacts: true. Sans needs, les artefacts des jobs du stage precedent sont disponibles par defaut (dependencies implicites). Pour eviter de telecharger des artefacts lourds inutilement :
job-sans-artefacts:
dependencies: [] # desactive l'heritage automatique