Rozdział 23 · Część V · Sprawdzamy i automatyzujemy

GitHub Actions: automatycznie wykonuje testy

Jeden plik workflow uruchamia testy SafeSort automatycznie przy każdej zmianie — bez ręcznej weryfikacji przed Pull Request.

SafeSort · Część 5 z 6Testy i CI
GitHubWalidacja (CI) to czwarty krok z diagramu na poprzedniej stronie

Łatwo zapomnieć o ręcznym sprawdzeniu testów przed każdym Pull Request. GitHub Actions jest usługą, która automatycznie wykonuje określone działania, gdy Konkretne zdarzenia w repozytorium, na przykład za każdym razem, gdy Pull Request. jest wypychany lub otwierany Dla SafeSort jest to przeprowadzanie testów.

push /pull_requestzdarzenie w repozytoriumworkflow YAMLGitHub czytaplik-instrukcjaRunner GitHubmaszyna wirtualnapodnosi się iotrzymuje kodpytesttesty wykonująwewnątrz runnera✓ / ✗wynik jest widoczny wPull Request
Od zdarzenia repozytorium do zielonego lub czerwonego znaczka Pull Request
Lista przebiegów GitHub Actions repozytorium Cartesian-School/safesort: 19 rzeczywistych przebiegów; spośród dwóch czerwonych jeden odnosi się do wczesnego etapu przed CI roboczym, drugi do testu celowo zepsutego, a zaraz po nim zielony
Prawdziwa historia CI repozytorium SafeSort to 19 przebiegów: jeden wczesny czerwony przed CI roboczym oraz treningowa para celowo uszkodzonych startów i zielonych po naprawie (sekcja poniżej).

Oto plik instrukcji, który GitHub odczytuje przed każdym uruchomieniem:

.github/workflows/safesort-tests.yml
name: SafeSort tests

on:
  push:
    branches: ["main"]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v7

      - name: Set up Python
        uses: actions/setup-python@v7
        with:
          python-version: "3.14"

      - name: Install SafeSort with dev dependencies
        run: pip install -e ".[dev]"

      - name: Run tests
        run: pytest tests/
on: nieograniczone, ponieważ cały repozytorium jest SafeSort
Tu nie ma klucza pathsograniczający działanie zmodyfikowanych plików: w osobnym repozytorium safesort jakiekolwiek Pull Request czy push w taki czy inny sposób dotyczy samego pakietu. Takie ograniczenie jest potrzebne tylko w repozytorium kursów ogólnych, gdzie SafeSort jest tylko jednym z wielu podkatalogów i nie ma potrzeby restartowania testów z powodu zmian gdzie indziej.

Kontrolowane sprawdzenie: celowo zepsyty test

Warto choć raz zobaczyć, jak wygląda czerwony (nieudany) test — i jak wygląda napraw to, zanim po raz pierwszy spotkasz się z tym w rzeczywistej sytuacji. W historii premiery To jest czerwony kółko powyżej: tymczasowe zatwierdzenie celowo zwracało wielkość liter porównanie rozszerzeń w klasyfikatorze (ten sam błąd co w sekcji 23-23 jako RED/GREEN przykład), został następnie cofnięty przez następne zatwierdzenie main nie przez sekundę pozostał w stanie złamanym.

Złamanie testucelowo zmieniaćwartość oczekiwaną przezniepoprawneWypychać gałąźGitHub Actionssię zaczynaautomatycznieCzerwona kontrolaotworzyć dziennik izobaczyć dokładny powódwodospadNaprawazwrócić poprawnewartości, zaangażuj sięZielony Czekten sam workflowzaczyna się od nowa iodbywa się
Złamanie testu raz celowo to najszybszy sposób, by nauczyć się czytać magazyn GitHub Actions
Główna gałąź nie powinna pozostać czerwona
Celem tego ćwiczenia jest natychmiastowe sprawdzenie nieudanego testu w kontrolowanym środowisku i jego natychmiastowe naprawienie, a nie zostawienie go main w uszkodzonym stanie. Rzeczywista, czerwona weryfikacja na głównej gałęzi oznacza, że ktoś inny, kto pobierze kod teraz, otrzyma nie działającą wersję.

Krótko

  • GitHub Actions automatycznie uruchamia określone działania — podczas naciskania lub otwierania Pull Request.
  • W osobnym repozytorium workflow uruchamia się bez ograniczeń dla paths — jakakolwiek zmiana tutaj w ten czy inny sposób dotyczy SafeSort.
  • Specjalnie popsuty, a następnie naprawiony test — szybki sposób, aby nauczyć się czytać dziennik kontroli.