Weryfikowanie zmian za pomocą GitHub Actions

W modelu programowania opartego na jednej gałęzi każda proponowana zmiana przechodzi przez pull request. To zgłoszenie zmian to również naturalny moment, aby uruchomić zautomatyzowane kontrole. Zmiana, która psuje skrypt treningowy, nie powinna trafić do main, a recenzent nie powinien musieć ręcznie wyłapywać każdego błędu w kodzie.

Przepływy pracy, wyzwalacze i brama jakości

Przepływ pracy GitHub Actions to plik YAML przechowywany w repozytorium w obszarze .github/workflows/. Definiuje to, co należy uruchomić, kiedy go uruchomić i w jakiej sekwencji. Wyzwalacz (on:klucz) informuje GitHub, kiedy należy go uruchomić.

W przepływie pracy weryfikacji Proseware wyzwalacz pull_request sprawdza się w tym zadaniu. Domyślnie uruchamia się, gdy pull request zostanie otwarty, otwarty ponownie lub otrzyma nowe commity. Jego wynik pojawia się jako kontrola stanu w pull requeście.

Zadania, moduły uruchamiacze i kroki

Przepływ pracy dzieli pracę na zadania. Każde zadanie jest uruchamiane na runnerze — maszynie wirtualnej udostępnianej przez GitHub lub zarządzanej przez Twoją organizację. Zadanie zawiera uporządkowane kroki , które sprawdzają repozytorium, instalują narzędzia i uruchamiają polecenia.

W przypadku kodu treningowego Proseware zadanie walidacji może wyglądać następująco:

1. Zapoznaj się z repozytorium.
2. Zainstaluj linter (taki jak Flake8 dla Python) i uruchom go względem skryptów szkoleniowych.
3. Uruchom testy jednostkowe (takie jak Pytest), aby sprawdzić, czy funkcje skryptu działają prawidłowo.

Te kroki uruchamiają się automatycznie dla każdego pull requestu. Nikt nie musi pamiętać, aby uruchomić je lokalnie.

Wymaganie kontroli

Uruchamianie testów automatycznie stanowi tylko połowę ochrony. Druga część polega na tym, że te kontrole są blokujące. W ustawieniach ochrony gałęzi opcja Wymagaj zaliczenia kontroli stanu przed scaleniem umożliwia określenie konkretnych zadań. Nie można scalić pull requestu, dopóki te wskazane zadania nie zakończą się powodzeniem.

Razem rozwój oparty na gałęzi głównej i wymagane kontrole statusu tworzą bramę jakości: analityk danych otwiera pull request, uruchamiany jest workflow, a przycisk scalania pozostaje wyłączony, dopóki kod nie przejdzie wszystkich kontroli.