Automatyczne testy i budowanie w pipeline
Złożysz kroki instalacji, Ruff, pytest i budowy obrazu w jedną bramkę jakości z raportem testów.
1. Krótka teoria
Pipeline powinien odtwarzać kroki, które działają lokalnie: pobranie kodu, ustawienie Pythona, instalację zależności, Ruff, pytest i budowę obrazu. W projekcie orders-api zakładamy, że requirements.txt zawiera także narzędzia testowe; jeśli projekt rozdziela zależności, workflow musi instalować odpowiednią grupę. Kolejność ma znaczenie: gdy Ruff lub pytest zwróci kod różny od zera, job kończy się błędem i obraz nie powinien stać się kandydatem do wydania. docker build sprawdza, czy aplikacja daje się spakować, ale sam w sobie nie publikuje obrazu do registry. pytest --junitxml zapisuje wynik w pliku. actions/upload-artifact może zachować raport także po niepowodzeniu testów, gdy krok ma if: always(). Artifact nie powinien zawierać haseł, danych osobowych ani pliku env. Nazwa artifactu ułatwia powiązanie go z uruchomieniem. Warto sprawdzić wersje używanych akcji i przypinać je zgodnie z polityką projektu, a przy wyższych wymaganiach bezpieczeństwa do pełnych commit SHA. Przed rozbudową workflow upewnij się, że te same komendy przechodzą lokalnie.
2. Przykłady komend
python -m pip install -r requirements.txt
Instaluje zależności z wersjonowanego pliku.
$ python -m pip install -r requirements.txt
ruff check .
Kończy krok błędem, gdy kod narusza reguły Ruff.
$ ruff check .
pytest --junitxml=reports/pytest.xml
Uruchamia testy i zapisuje raport JUnit.
$ pytest --junitxml=reports/pytest.xml
docker build -t orders-api:ci .
Sprawdza budowę obrazu bez publikowania do registry.
$ docker build -t orders-api:ci .
- uses: actions/checkout@v4
Przykładowy krok YAML pobierający kod w istniejącej wersji akcji.
- name: Pobierz kod
uses: actions/checkout@v4
- uses: actions/setup-python@v5
Przykładowy krok YAML wybierający Pythona.
- name: Ustaw Python
uses: actions/setup-python@v5
with:
python-version: '3.12'
- uses: actions/upload-artifact@v4
Przykładowy krok YAML zapisujący raport także po błędzie testów.
- name: Zachowaj raport
if: always()
uses: actions/upload-artifact@v4
with:
name: pytest-report
path: reports/pytest.xml3. Zadanie praktyczne
checks dla orders-api: zainstaluj zależności, uruchom ruff check ., pytest --junitxml=reports/pytest.xml i dopiero potem docker build -t orders-api:ci .. Dodaj krok upload-artifact dla raportu z if: always(). Wymuś lokalnie jeden błąd testu i opisz, który krok joba powinien się zatrzymać oraz dlaczego raport ma pozostać dostępny.
4. Typowe błędy
- Budowanie lub publikowanie obrazu mimo niepowodzenia testów.
- Zakładanie, że runner ma zależności projektu bez instalacji.
- Przesyłanie w artifactach plików env lub prywatnych danych.
- Uznawanie udanej budowy obrazu za test działania aplikacji.
- Pomijanie raportu po błędzie przez brak if: always().
5. Podsumowanie
Kroki CI powinny odtwarzać lokalny quality gate i zatrzymywać dalsze działania po błędzie. Budowa obrazu weryfikuje pakowanie, a raport testów jako artifact ułatwia diagnozę. Publikowanie i wdrażanie wymagają osobnej decyzji.