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.

Artefact transmet une sortie attendue au job suivant; cache fournit une entrée réutilisable pour accélérer le build.

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

  1. Caching in GitLab CI/CDGitLab Docs
  2. Job artifactsGitLab Docs
  3. CI/CD YAML syntax referenceGitLab Docs