Architecture / CI-CD
Un job CI manque-t-il d’un fichier requis ou seulement d’un cache ?
Éviter qu’une pipeline dépende d’une donnée facultative : choisir artefact ou cache selon ce que le job suivant doit pouvoir reconstruire.
Un job termine en vert mais le suivant échoue parce qu’il ne trouve pas le fichier attendu. Le premier diagnostic consiste à distinguer une sortie indispensable d’une donnée qu’on peut reconstruire. Dans GitLab CI, l’artefact transmet la première; le cache peut accélérer la seconde sans garantir sa présence.
Une pipeline avec les deux mécanismes
Nommez la sortie obligatoire : ici out/result.txt. Son absence doit faire échouer le consommateur, alors qu’une dépendance mise en cache peut être reconstruite. Disposez d’un projet GitLab CI et d’un runner avec un shell fournissant mkdir, printf, test et cat. Ce YAML décrit un flux à configurer, sans rapporter une pipeline exécutée.
stages: [build, check]
build:
stage: build
cache:
key: "demo-dependencies"
paths:
- .cache/dependencies/demo-lib.txt
policy: push
script:
- mkdir -p out .cache/dependencies
- printf 'résultat produit\n' > out/result.txt
- printf 'dépendance fictive\n' > .cache/dependencies/demo-lib.txt
artifacts:
paths:
- out/result.txt
check-result:
stage: check
needs:
- job: build
artifacts: true
cache:
key: "demo-dependencies"
paths:
- .cache/dependencies/demo-lib.txt
policy: pull
script:
- test -f out/result.txt
- cat out/result.txt
- |
if [ -f .cache/dependencies/demo-lib.txt ]; then
printf 'cache présent : dépendance réutilisée\n'
else
printf 'cache absent : reconstruction de la dépendance\n'
mkdir -p .cache/dependencies
printf 'dépendance fictive\n' > .cache/dependencies/demo-lib.txt
fi
- test -f .cache/dependencies/demo-lib.txt
build transmet out/result.txt sous forme d’artefact. needs nomme le producteur et demande explicitement ses artefacts. La réception de ce fichier est le résultat attendu du lien déclaré entre ces jobs; elle ne dépend pas du cache. test -f out/result.txt contrôle sa présence, sans valider son contenu métier : ajoutez les assertions correspondant au format et au résultat demandé.
Le cache contient une dépendance recréable. build peut la pousser; check-result la demande en lecture seule. Si elle manque — cache froid, indisponible ou non partagé — le script la reconstruit. La valeur mise en cache ici est volontairement fictive : le scénario illustre le flux, sans téléchargement ni registre externe.
Comment choisir
| Besoin | Mécanisme | Si la donnée manque |
|---|---|---|
| Transmettre au job suivant une sortie précise du producteur | Artefact déclaré sous artifacts:paths et récupéré par le consommateur |
Le job doit échouer ou traiter explicitement l’absence de la sortie attendue |
| Réutiliser des dépendances ou résultats intermédiaires pour accélérer | Cache avec une clé et des chemins adaptés | Le job doit pouvoir retélécharger ou reconstruire ce qui est nécessaire |
Un cache est une optimisation dont la présence dépend du stockage et de la configuration des runners. L’artefact transmet une sortie déclarée; sa conservation dépend de expire_in et des réglages de l’instance. Vérifiez le fichier obligatoire et faites échouer le job s’il manque. Traitez l’absence de cache comme un chemin normal de reconstruction.
Quand needs est utilisé, déclarez les producteurs attendus et leur option artifacts; ne supposez pas que tous les artefacts des stages précédents seront récupérés.
Sources techniques
- Caching in GitLab CI/CDGitLab Docs
- Job artifactsGitLab Docs
- CI/CD YAML syntax referenceGitLab Docs