Testing Files Generator
Français

Comment générer des fichiers de test dans un pipeline CI

Une fixture binaire dans un dépôt reste à jamais dans son historique, ne se relit pas dans un diff et devient impossible dès que le fichier est gros. Générez plutôt les fichiers dans le pipeline à partir d'une recette. La recette est du texte, les octets sortent identiques à chaque fois, et une dernière étape prouve que rien n'a bougé.

La réponse courte

Installez tfg, lancez tfg generate fixtures.yaml --out ./fixtures avant les tests et tfg verify ./fixtures/manifest.json après. Les deux étapes font échouer le build d'elles-mêmes, avec un code de sortie qui dit pourquoi.

Pourquoi ne pas les commiter

Pourquoi une fixture ne doit pas vivre dans le dépôt

C'est la recette qu'il faut commiter. La même recette et la même graine écrivent les mêmes octets sur toute machine, donc le fichier généré dans le pipeline est celui que vous aviez sur votre portable.

La recette

Une recette qui vit à côté des tests

Celle-ci écrit vingt-cinq factures qui doivent être acceptées et deux images au-dessus d'une limite qui doivent être refusées, et le manifeste note les deux attentes : 

version: 1
seed: 7741

targets:
  - id: invoices
    format: pdf
    count: 25
    size: 300kb
    expected: accept

  - id: over_the_limit
    format: png
    count: 2
    size: 12mb
    expected:
      outcome: reject
      reason: size_limit

tfg validate fixtures.yaml la vérifie sans rien écrire et nomme tous les problèmes d'un coup.

GitHub Actions

Un workflow qui installe l'outil et construit les fixtures

jobs:
  test:
    runs-on: ubuntu-latest
    env:
      TFG_VERSION: "0.4.0"
    steps:
      - uses: actions/checkout@v4

      - name: install tfg
        run: |
          base=https://github.com/donislawdev/TestingFilesGenerator/releases/download/v$TFG_VERSION
          curl -fsSLO "$base/tfg_${TFG_VERSION}_linux_amd64.tar.gz"
          curl -fsSLO "$base/verify-SHA256SUMS.txt"
          sha256sum --check --ignore-missing verify-SHA256SUMS.txt
          tar -xzf "tfg_${TFG_VERSION}_linux_amd64.tar.gz" ./tfg
          sudo mv tfg /usr/local/bin/

      - name: build the fixtures
        run: tfg generate fixtures.yaml --out ./fixtures

      - name: run the tests
        run: pytest tests/

      - name: nothing moved
        run: tfg verify ./fixtures/manifest.json

La ligne de somme de contrôle compare l'archive à verify-SHA256SUMS.txt de la même version. La version est épinglée, donc une nouvelle version ne change jamais un build que vous n'avez pas touché.

GitLab CI

La même chose en job GitLab

fixtures:
  image: ubuntu:24.04
  variables:
    TFG_VERSION: "0.4.0"
  script:
    - apt-get update -qq && apt-get install -y -qq curl ca-certificates
    - base=https://github.com/donislawdev/TestingFilesGenerator/releases/download/v$TFG_VERSION
    - curl -fsSLO "$base/tfg_${TFG_VERSION}_linux_amd64.tar.gz"
    - curl -fsSLO "$base/verify-SHA256SUMS.txt"
    - sha256sum --check --ignore-missing verify-SHA256SUMS.txt
    - tar -xzf "tfg_${TFG_VERSION}_linux_amd64.tar.gz" ./tfg
    - ./tfg generate fixtures.yaml --out ./fixtures
    - pytest tests/
    - ./tfg verify ./fixtures/manifest.json

Quand ça passe au rouge

Ce qui fait échouer une étape, et pourquoi

Chaque fin a son propre code de sortie, donc l'étape échoue d'elle-même et le journal dit lequel. Ceux que rencontre un pipeline :

Une exécution échouée n'écrit rien sur la sortie standard, donc un analyseur de journaux ne prend jamais une erreur pour des données. Le tableau complet est sur la page de documentation.

PowerShell

Un script PowerShell demande une ligne de plus

PowerShell ne fait pas sortir le code de sortie d'un programme d'un fichier .ps1. Lancez-en un avec -File et le script répond 0 même quand l'outil à l'intérieur a refusé le travail, si bien qu'un build qui devrait être rouge passe au vert. La dernière ligne est toute la correction : 

tfg generate fixtures.yaml --out ./fixtures
exit $LASTEXITCODE

C'est ainsi que se comporte PowerShell, pas une particularité de cet outil. cmd, bash et zsh n'ont besoin de rien de plus.

Plusieurs jobs

Partager les fixtures entre les jobs

Il n'y a généralement pas besoin de les envoyer. Comme la même recette écrit les mêmes octets, chaque job peut lancer son propre tfg generate, ce qui est plus rapide qu'un envoi suivi d'un téléchargement. Quand un job doit recevoir des fichiers d'un autre, lancez tfg verify sur le manifeste après le transfert, et il dit si ce qui est arrivé est ce qui a été écrit.

Suite

Où aller ensuite