Jak generować pliki testowe w potoku CI

Dlaczego nie commitować

Dlaczego pliku testowego nie powinno być w repozytorium

• Zostaje w historii. Usunięcie pliku binarnego później nie zmniejsza klonu, bo każda jego wersja nadal tam jest.
• Różnice nie pokażą, co się zmieniło. Recenzent widzi, że PDF jest inny, i nic więcej. Przepis zmienia się o jedną linię.
• Duże pliki się nie mieszczą. GitHub odrzuca push z plikiem większym niż 100 MB, więc test limitu uploadu 500 MB nie ma czego commitować.

Commitować trzeba przepis. Ten sam przepis i ziarno zapisują te same bajty na każdej maszynie, więc plik wygenerowany w potoku jest tym plikiem, który miałeś na laptopie.

Przepis

Przepis, który leży obok testów

Ten zapisuje dwadzieścia pięć faktur, które powinny zostać przyjęte, i dwa obrazy ponad limitem, które powinny zostać odrzucone, a manifest zapisuje oba oczekiwania:

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 sprawdza go, nic nie zapisując, i od razu wymienia każdy problem.

GitHub Actions

Workflow, który instaluje narzędzie i buduje pliki testowe

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

Wiersz z sumą kontrolną porównuje archiwum z verify-SHA256SUMS.txt z tego samego wydania. Wersja jest przypięta, więc nowe wydanie nigdy nie zmieni buildu, którego nie ruszałeś.

GitLab CI

To samo jako zadanie GitLaba

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

Gdy robi się czerwono

Co przerywa krok i dlaczego

Każde zakończenie ma własny kod wyjścia, więc krok sam się przerywa, a log mówi, który to był. Te, które spotyka potok:

• 3 - przepis jest niepoprawny. Nic nie zapisano, a każdy problem jest nazwany
• 4 - format nie potrafi tego, o co poproszono, na przykład rozmiaru poniżej swojego najmniejszego
• 6 - brakuje miejsca na dysku
• 7 - tfg verify znalazł plik, który nie zgadza się z manifestem
• 8 - przebieg się skończył, ale nie wszystko powstało

Nieudany przebieg nie wypisuje niczego na standardowe wyjście, więc parser logów nigdy nie weźmie błędu za dane. Cała tabela jest na stronie dokumentacji.

PowerShell

Skrypt PowerShella potrzebuje jeszcze jednej linii

PowerShell nie wynosi kodu wyjścia programu poza plik .ps1. Uruchom go z -File, a skrypt odpowie 0, nawet gdy narzędzie w środku odmówiło pracy, więc build, który powinien być czerwony, robi się zielony. Ostatnia linia to cała poprawka:

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

Tak zachowuje się PowerShell, a nie to narzędzie. cmd, bash i zsh nie potrzebują niczego więcej.

Kilka zadań

Przekazywanie plików testowych między zadaniami

Zwykle nie trzeba ich wysyłać. Skoro ten sam przepis zapisuje te same bajty, każde zadanie może uruchomić własne tfg generate, co jest szybsze niż wysyłanie i pobieranie. Gdy zadanie musi dostać pliki z innego, uruchom tfg verify na manifeście po przesłaniu, a powie, czy to, co dotarło, jest tym, co zapisano.

Dalej

Dokąd pójść stąd

• Uszkodzone pliki testowe dokładają do tego samego przepisu pliki zepsute celowo.
• Zastosowania pokazują, co jeszcze może sprawdzić przebieg w potoku.
• Dokumentacja ma każde polecenie, klucz przepisu i kod wyjścia.