GitHub Actions to fantastyczny sposób na uruchamianie przepływów pracy ciągłej integracji, od uruchamiania testów po sprawdzanie analizy statycznej i nie tylko.
W aplikacjach Laravel kluczowe znaczenie ma uruchamianie procesów przepływu pracy, aby upewnić się, że kod jest zgodny z określonym standardem. Zanim mieliśmy potok CI, uruchamialiśmy wszystkie te przepływy pracy lokalnie — co powodowało problemy, gdy inni zapomnieli je uruchomić.
W tym samouczku przejdę przez konfigurowanie akcji GitHub dla aplikacji Laravel, abyś mógł z radością usiąść i upewnić się, że kod jest gotowy do uruchomienia.
Początkiem tego procesu jest dodanie katalogu w katalogu głównym projektu, .github/workflows. Tutaj dodajemy nasze pliki przepływu pracy, aby GitHub mógł pobrać każdy z nich i uruchomić go osobno. Od tego momentu możesz zaprojektować procesy przepływu pracy tak, jak ich potrzebujesz, od oddzielnych przepływów pracy dla każdej części - po połączenie ich wszystkich w jeden przepływ pracy.
Zacznę od przepływu pracy testu, ponieważ jest to najbardziej prawdopodobny na początek. Nawet jeśli zaimplementujesz ten jeden przepływ pracy, zrobiłeś krok we właściwym kierunku.
Nie zrobię pełnego przewodnika po tym, jak powinieneś budować akcje GitHub, ponieważ jest to dość skomplikowany temat, który jest bardzo specyficzny dla tego, jak chcesz je wdrożyć. Przepływ pracy będzie budowany krok po kroku, co pozwoli nam zrozumieć, jak to działa.
name: Run tests
on: [push]
Na początek musimy nadać przepływowi pracy nazwę, coś, czego GitHub użyje do wyświetlenia, co się dzieje. Następnie dodajemy wpis on, informując GitHub, na jakich zdarzeniach powinien być uruchomiony ten przepływ pracy. Możesz dodać tutaj więcej niż jedno i istnieje szeroki zakres wydarzeń, których możesz użyć.
Naszym następnym krokiem jest zdefiniowanie zadań, które chcemy uruchamiać. Każdy przepływ pracy może zawierać wiele zadań. Jednak zazwyczaj trzymam się jednego zadania na przepływ pracy, aby było to proste.
name: Run tests
on: [push]
jobs:
tests:
name: Run tests
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
extensions: dom, curl, libxml, mbstring, zip, pcntl, pdo, sqlite, pdo_sqlite, bcmath, soap, intl, gd, exif, iconv
coverage: none
- name: Run composer install
run: composer install -n --prefer-dist
- name: Prepare Laravel Application
run: |
cp .env.ci .env
php artisan key:generate
- name: Run tests
run: php artisan test
Nasze zadanie ma nazwę dla GitHub, aby używać jej jako etykiety podczas wyświetlania tego, co się dzieje. Musimy określić, na czym będzie polegało to zadanie. Tutaj używam ubuntu-najnowszego, ponieważ jest to zazwyczaj moje docelowe wdrożenie. Istnieje wiele opcji, ukierunkowanych na określone wersje systemu operacyjnego, a nawet różne dostępne systemy operacyjne. Nasze zadanie składa się z wielu kroków, które zadanie musi wykonać, aby je uruchomić, od wyewidencjonowania kodu do wykonania tego, co należy zrobić.
Większość zadań rozpocznie się od akcji kasy, oficjalnej akcji zespołu w GitHub. Używam tutaj wersji 3, ponieważ obsługuje najnowszą wersję węzła dla dowolnego JavaScript w moim projekcie. Jeśli potrzebujesz konkretnej wersji węzła, zapoznaj się z informacjami o wersji każdej wersji, aby upewnić się, że spełniasz swoje wymagania.
Następnie używamy akcji shivammathur/setup-php@v2, której używamy do konfiguracji naszego środowiska PHP. Przekazanie naszej wersji PHP i wszelkich rozszerzeń PHP wymaganych do zainstalowania.
Następnie instalujemy nasze zależności PHP, aby upewnić się, że nasza instalacja jest płynna, jeśli chodzi o późniejsze wdrożenie. W każdym kroku można uruchomić akcję pakietową lub polecenie interfejsu wiersza polecenia, które można uruchomić. Następnie konfigurujemy naszą aplikację Laravel, uruchamiając dowolne polecenia rzemieślnicze lub cokolwiek innego, co możemy zrobić. W moim projekcie używam bazy danych SQLite uruchomionej w pamięci dla mojej testowej bazy danych. Jeśli używasz czegoś innego, istnieje wiele dostępnych opcji, które są dobrze udokumentowane. Wszystko, co robię w moim, to kopiowanie określonego pliku .env.ci do pliku .env, którego aplikacja będzie używać. Następnie możemy wygenerować klucz szyfrowania aplikacji za pomocą polecenia artisan.
Naszym ostatnim krokiem jest uruchomienie naszego zestawu testów, którego używam za pomocą polecenia testu rzemieślniczego. Możesz wywołać testowy plik binarny samodzielnie lub użyć polecenia artisan. Do tego polecenia można również dodać dodatkowe opcje, które mogą być potrzebne do debugowania potencjalnych błędów testów w ramach CI.
Teraz, gdy nasz początkowy przepływ pracy jest uruchomiony, możemy spojrzeć na inny. Tym razem użyjemy jednego z moich ulubionych przepływów pracy do uruchomienia, analizy statycznej. Jak wiele osób może już wiedzieć, jestem zdeklarowanym programistą, który zawsze macha flagą analizy statycznej.
W tej następnej części nie będę ponownie przechodził przez wszystkie kroki. Zamiast tego skupimy się na ostatniej części.Ponieważ nie
name: Static Analysis
on: [push]
jobs:
phpstan:
name: phpstan
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
coverage: none
- name: Install composer dependencies
run: composer install -n --prefer-dist
- name: Run Static Analysis
run: ./vendor/bin/phpstan --error-format=github
potrzebujemy aplikacji do uruchomienia, tym razem nie musimy się martwić o wszystkie zależności PHP. Naszym ostatnim krokiem jest uruchomienie samej analizy statycznej. Osobiście używam PHPStan do mojej analizy statycznej wyboru. Będzie to jednak działać z dowolną dostępną biblioteką analizy statycznej. Przekazuję flagę error-format, aby wszelkie potencjalne błędy były w formacie, który GitHub może zrozumieć i są przeznaczone dla środowiska CI.
Możesz pójść dalej, na przykład uruchamiając Laravel Pint lub więcej. Jednak jako wstęp myślę, że obejmuje to, czego będziesz potrzebować.
