Zarządzanie przepływami pracy i debugowanie ich w funkcji GitHub Actions

10 min

Pamiętaj, że Twoim celem jest zautomatyzowanie procesu kompilowania i publikowania kodu, dzięki czemu funkcje są aktualizowane za każdym razem, gdy deweloper dodaje zmianę do bazy kodu.

Aby zaimplementować ten proces, dowiesz się, jak wykonywać następujące czynności:

Zidentyfikuj zdarzenie, które wyzwoliło przepływ pracy.
Użyj dzienników przepływu pracy funkcji GitHub Actions.
Zapisz artefakty kompilacji i uzyskaj do nich dostęp.
Automatyzowanie dodawania etykiety do pull requestu po zakończeniu przeglądu.

Identyfikowanie zdarzenia, które wyzwoliło przepływ pracy

Zrozumienie, co uruchomiło przepływ pracy w GitHub Actions, ma kluczowe znaczenie dla debugowania, audytu i ulepszania potoków CI/CD. Typ wyzwalaczy obejmuje wypychanie do gałęzi, żądanie ściągnięcia utworzone lub zaktualizowane, zaplanowane zadanie lub ręczne wysłanie. Zdarzenie wyzwalające można zidentyfikować, analizując przebieg przepływu pracy, zmiany w repozytorium oraz związane z tym zagadnienie na GitHubie lub żądanie zatwierdzenia.

Diagram przedstawiający różne wyzwalacze przepływu pracy w funkcji GitHub Actions, takie jak wypychanie, żądanie ściągnięcia, harmonogram i ręczne wysyłanie.

Co to jest wyzwalacz przepływu pracy?

Wyzwalacz przepływu pracy to zdarzenie, które powoduje uruchomienie przepływu pracy. Usługa GitHub obsługuje różne typy wyzwalaczy, w tym:

push lub pull_request (na podstawie zmian kodu)
workflow_dispatch (wyzwalacz ręczny)
schedule (zadania cron)
repository_dispatch (systemy zewnętrzne)
Zdarzenia dotyczące problemów, dyskusji i żądań ściągnięcia (na przykład issues.opened, pull_request.closed)

Identyfikowanie zdarzenia wyzwalacza

Zdarzenie wyzwalacza przepływu pracy można zidentyfikować na wiele sposobów:

Użyj interfejsu użytkownika funkcji GitHub Actions:
1. W repozytorium wybierz kartę Akcje .
2. Wybierz przebieg przepływu pracy.
Typ zdarzenia, taki jak push, pull_requestlub workflow_dispatch, pojawia się w górnej części podsumowania przebiegu przepływu pracy.
Użyj github.event_name w dziennikach lub w przepływie pracy.
- Usługa GitHub uwidacznia dane kontekstowe podczas uruchamiania przepływu pracy. Zmienna github.event_name informuje, które zdarzenie wyzwoliło przepływ pracy.
- Informacje można wydrukować w kroku na potrzeby debugowania:
```
-name: Show event trigger
  run: echo "Triggered by ${{ github.event_name }}"
```
Skorzystaj ze szczegółów przebiegu workflowu.
- Jeśli analiza przepływu pracy jest wykonywana programowo, na przykład przy użyciu interfejsu API, obiekt uruchomienia zawiera właściwość określającą wyzwalacz event.
- Aby prześledzić przyczynę wyzwalacza, możesz znaleźć zatwierdzony algorytm wyznaczania wartości skrótu (SHA), aktora i znacznika czasu.

Wywnioskować działanie wyzwalacza na podstawie efektów repozytorium

Być może nie masz bezpośredniego dostępu do przebiegu przepływu pracy, ale nadal chcesz wywnioskować, co wyzwoliło uruchomienie przepływu pracy na podstawie działania repozytorium:

Obserwowane zachowanie	Zdarzenie wyzwalające
Nowy commit został wypchnięty do `main` i uruchomiono proces.	zdarzenie `push`
Prośba o pobranie została otwarta lub zaktualizowana.	zdarzenie `pull_request`
Współautor ręcznie uruchomił przepływ pracy.	`workflow_dispatch`
Przepływ pracy jest uruchamiany codziennie o określonej godzinie.	`schedule` (cron)
Przepływ pracy wystartował po wywołaniu usługi zewnętrznej.	`repository_dispatch`
Przepływ pracy został uruchomiony po dodaniu etykiety lub komentarza do problemu.	zdarzenie `issues.*`

Przeglądając znaczniki czasu, aktywność związana z żądaniami ściągnięcia i historię zatwierdzeń, często można dokładnie określić, która akcja spowodowała uruchomienie procesu pracy.

Jak zidentyfikować, co wywołało przepływ pracy:

Sprawdź podsumowanie przebiegu przepływu pracy na karcie Akcje .
Drukowanie lub rejestrowanie github.event_name wewnątrz przepływu pracy w celu uzyskania widoczności.
Porównaj znaczniki czasu i działanie repozytorium (zatwierdzenia, żądania ściągnięcia, problemy), aby wywnioskować wyzwalacz.
Użyj pełnego event kontekstu w celu dokładniejszego zbadania.

Te rozwiązania ułatwiają debugowanie, inspekcję i zwiększanie niezawodności przepływu pracy w potokach programowania i wdrażania.

Zrozumienie efektu przepływu pracy przez odczytanie jego pliku konfiguracji

Aby zrozumieć efekty przepływu zadań wynikające z odczytu jego pliku konfiguracji, przeanalizuj strukturę i zawartość pliku .yml przechowywanego w .github/workflows/.

Plik konfiguracji przepływu pracy określa następujące informacje o przepływie pracy:

Kiedy działa (w sekcji on).
Co to robi (w jobs i steps).
Gdzie działa (sekcja runs-on).
Dlaczego działa (jej cel, taki jak testowanie, wdrażanie lub analiza statyczna).
Jak zachowuje się w określonych warunkach (środowisko, filtry, logika).

Interpretowanie efektu przepływu pracy

Zidentyfikuj wyzwalacz.

Aby zidentyfikować akcję zainicjowaną przez przepływ pracy, zobacz on sekcję przepływu pracy.

Przykład:
```
on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:
```
Ten przykładowy przepływ pracy:
- Uruchamia się automatycznie, gdy kod jest wypychany do gałęzi głównej (push).
- Uruchamia się po utworzeniu lub zaktualizowaniu żądania ściągnięcia (pull_request).
- Można wyzwalać ręcznie przez użytkownika (workflow_dispatch).
Zidentyfikuj zadania i kroki przepływu pracy.

Aby określić, co robi przepływ pracy, zobacz sekcje jobs i steps.

Przykład:
```
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
```
Ten przykładowy przepływ pracy:
- Używa środowiska wirtualnego systemu Linux (runs-on).
- Sprawdź kod repozytorium (steps>name).
- Instaluje zależności projektu (steps>name).
- Uruchamia testy automatyczne (steps>name).
Oceń przeznaczenie i wynik przepływu pracy.

Odczytując plik konfiguracji, można opisać zamierzony wynik przepływu pracy:

"Ten przepływ pracy jest potokiem ciągłej integracji. Gwarantuje to, że każdy nowy kod wypchnięty do repozytorium lub przesłany za pośrednictwem żądania ściągnięcia zostanie automatycznie przetestowany. Jeśli testy kończą się niepowodzeniem, interfejs GitHub wyświetla ten rezultat, aby zapewnić utrzymanie jakości kodu.
Zidentyfikuj lub ustaw opcjonalne funkcje wpływające na sposób działania przepływu pracy:
- env ustawia zmienne środowiskowe.
- if Dodaje logikę warunkową do uruchamiania określonych kroków tylko wtedy, gdy kryteria są spełnione.
- timeout-minutes lub continue-on-error ustaw wykonywanie przepływu pracy i obsługę błędów.

Diagnozowanie nieudanego przebiegu przepływu pracy

W repozytorium przejdź do karty Akcje .
Znajdź przebieg, który zakończył się niepowodzeniem (zazwyczaj wskazywany przez czerwony symbol X).
Wybierz przepływ pracy, który zakończył się niepowodzeniem, aby otworzyć podsumowanie przebiegu.
W dziennikach przepływu pracy przejrzyj błąd.
1. W podsumowaniu przebiegu rozwiń każde zadanie i krok do momentu znalezienia tego, który wskazuje awarię.
2. Wybierz zadanie lub krok, aby wyświetlić jego dzienniki.
3. Wyszukaj:
  - Komunikaty o błędach
  - Ślady stosu
  - Kody zakończenia
Na przykład test, który zakończył się niepowodzeniem, może być wyświetlany npm ERR! Test failed lub exit code 1.
Sprawdź plik konfiguracji przepływu pracy.

Aby określić, użyj pliku .yml
- Co każdy krok próbował zrobić?
- Jeśli istnieją zmienne środowiskowe (env) lub warunkowe (if), które mają wpływ na wykonywanie.
- Jeśli błąd jest spowodowany brakującą zależnością, błędem składni lub nieprawidłowo skonfigurowanym krokiem.
Jeśli krok zakończy się niepowodzeniem, sprawdź następujące przyczyny:
- Czy zależności zostały pomyślnie zainstalowane w poprzednim kroku?
- Czy pliki testowe istnieją i są przekazywane lokalnie?

Typowe scenariusze błędów

W poniższej tabeli opisano typowe scenariusze błędów przepływu pracy:

Objaw	Prawdopodobna przyczyna
Krok kończy się niepowodzeniem i zwraca `command not found`l	Brak zależności lub nieprawidłowej konfiguracji
`npm install` Nie powiedzie się.	Uszkodzony `package-lock.json` plik lub problem z siecią
Krok testowy kończy się niepowodzeniem	Problemy z testem jednostkowym, brak pliku konfiguracji lub nieprawidłowa składnia testu
`Permission denied` Pojawia się.	Nieprawidłowe uprawnienia do pliku lub brakujące tajne dane

Identyfikowanie sposobu uzyskiwania dostępu do dzienników przepływu pracy w usłudze GitHub

W repozytorium przejdź do karty Akcje .
Na liście przepływów pracy wybierz odpowiedni przepływ pracy.

Jeśli na przykład plik .yml ma następujący kod, na liście zostanie wyświetlony link zatytułowany CI Workflow:
```
name: CI Workflow
```
Wybierz konkretny przebieg.

Na liście operacji pokazujących stan wybierz datę i godzinę lub komunikat zatwierdzenia konkretnej operacji, którą chcesz sprawdzić.
Rozwiń każde zadanie i krok.

Na stronie podsumowania przebiegu są wyświetlane zadania zdefiniowane w pliku przepływu pracy, takie jak kompilacja lub testowanie:
1. Wybierz zadanie, aby je rozwinąć.
2. Wewnątrz zadania rozwiń poszczególne kroki, takie jak "Instalowanie zależności" lub "Uruchamianie testów".
Wyświetlanie danych wyjściowych dziennika.

Aby wyświetlić pełne dane wyjściowe dziennika, w tym dzienniki konsoli, komunikaty o błędach i informacje debugowania, wybierz krok przepływu pracy. Możesz kopiować, wyszukiwać i pobierać dzienniki.

Poniższa tabela zawiera podsumowanie czynności, które należy wykonać w celu uzyskania dostępu do dzienników przepływu pracy:

Akcja	Przeznaczenie
Karta Akcje	Wyświetl wszystkie przebiegi pracy.
Wybierz nazwę przepływu pracy	Filtruj uruchomienia według przepływu pracy.
Wybierz przebieg	Zobacz konkretne zadanie i wyniki kroków.
Rozwiń kroki	Wyświetl szczegółowe dzienniki.
Pobieranie dzienników	Pobierz dzienniki do rozwiązywania problemów offline lub przez zespół.

Dzienniki zdarzeń kompilacji

Po uruchomieniu przepływu pracy tworzony jest dziennik zawierający szczegółowe informacje o tym, co się wydarzyło, oraz wszelkie błędy lub niepowodzenia testów.

Jeśli wystąpi błąd lub test zakończy się niepowodzeniem, w dziennikach pojawi się czerwony znak X zamiast zielonego znacznika wyboru. Możesz sprawdzić szczegóły błędu lub awarii, aby zbadać, co się stało.

Zrzut ekranu przedstawiający dziennik funkcji GitHub Actions ze szczegółowymi informacjami na temat testu, który zakończył się niepowodzeniem.

Praca z artefaktami

Gdy przepływ pracy generuje coś innego niż wpis dziennika, produkt jest nazywany artefaktem . Na przykład kompilacja Node.js tworzy kontener platformy Docker, który można wdrożyć. Kontener jest artefaktem, który można załadować do magazynu, korzystając z akcji actions/upload-artifact. Później możesz pobrać artefakt z magazynu przy użyciu akcji/download-artifact.

Przechowywanie artefaktu zachowuje go między zadaniami. Nie można ponownie wykorzystać artefaktu, zapisując go na maszynie wirtualnej, ponieważ każde zadanie używa nowego wystąpienia maszyny wirtualnej. Jeśli potrzebujesz artefaktu w innym zadaniu, możesz przekazać artefakt do magazynu w jednym zadaniu i pobrać go dla drugiego zadania.

Magazyn artefaktów

Artefakty są przechowywane w miejscu do magazynowania w usłudze GitHub. Przestrzeń jest dostępna za darmo dla repozytoriów publicznych, a część przestrzeni dyskowej jest dostępna za darmo dla repozytoriów prywatnych, w zależności od posiadanego konta użytkownika. Usługa GitHub przechowuje artefakty przez 90 dni.

W poniższym fragmencie przepływu pracy zwróć uwagę, że w akcji actions/upload-artifact@main znajduje się atrybut path. Wartość tego atrybutu to ścieżka do przechowywania artefaktu. W tym przykładzie wskazujesz public/, aby przesłać wszystko do katalogu. Jeśli chcesz przekazać tylko jeden plik, użyj czegoś takiego jak publiczny/mytext.txt.

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@main
        with:
          name: webpack artifacts
          path: public/

Aby pobrać artefakt do testowania, kompilacja musi zakończyć się pomyślnie i załadować artefakt. W poniższym kodzie określisz, że zadanie testowe zależy od zadania kompilacji.

test:
    needs: build
    runs-on: ubuntu-latest

W poniższym fragmencie przepływu pracy pobierzesz artefakt. Teraz zadanie testowe może używać artefaktu do testowania.

steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public

Aby uzyskać więcej informacji na temat używania artefaktów w przepływach pracy, zobacz Przechowywanie danych przepływu pracy jako artefaktów.

Automatyzowanie przeglądów w usłudze GitHub przy użyciu przepływów pracy

Oprócz uruchamiania przepływu pracy za pośrednictwem zdarzeń usługi GitHub, takich jak push i pull-request, można uruchomić przepływ pracy zgodnie z harmonogramem lub po pewnym zdarzeniu poza usługą GitHub.

Przepływ pracy może zostać uruchomiony dopiero po tym, jak użytkownik wykona określone działanie, na przykład po tym, jak recenzent zatwierdzi żądanie ściągnięcia. Dla tego scenariusza, można uruchomić na pull-request-review.

Możesz również dodać etykietę do pull request. W takim przypadku użyj akcji pullreminders/label-when-approved-action.

Przykład:

    steps:
     - name: Label when approved
       uses: pullreminders/label-when-approved-action@main
       env:
         APPROVALS: "1"
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         ADD_LABEL: "approved"

env W bloku ustawiasz zmienne środowiskowe dla akcji. Można na przykład ustawić liczbę osób zatwierdzających wymaganych do uruchomienia przepływu pracy. W tym przykładzie jest to jeden. Wymagana jest zmienna uwierzytelniania secrets.GITHUB_TOKEN, ponieważ akcja musi wprowadzać zmiany w repozytorium przez dodanie etykiety. Na koniec wprowadź nazwę etykiety do dodania.

Dodawanie etykiety może być zdarzeniem, które uruchamia inny przepływ pracy, na przykład scalanie. To wydarzenie zostanie omówione w kolejnym module, w którym opisano używanie ciągłego dostarczania w usłudze GitHub Actions.

Sprzężenie zwrotne

Czy ta strona była pomocna?