Buforowanie, udostępnianie i debugowanie przepływów pracy

8 min

W tej lekcji dowiesz się, jak zoptymalizować wydajność, przekazywać dane między zadaniami i rozwiązywać problemy z przepływami pracy przy użyciu dzienników i tokenów.

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

Zależności pamięci podręcznej dla szybszych przepływów pracy.
Przekazywanie danych artefaktu między zadaniami.
Włącz rejestrowanie debugowania dla przepływów pracy.
Uzyskaj dostęp do dzienników przepływu pracy z interfejsu użytkownika usługi GitHub i interfejsu API REST.
Użyj tokenów instalacyjnych na potrzeby uwierzytelniania aplikacji GitHub.

Zależności pamięci podręcznej z akcją pamięci podręcznej

Podczas kompilowania przepływu pracy często trzeba ponownie użyć tych samych danych wyjściowych lub pobrać zależności z jednego uruchomienia do innego. Zamiast ponownie pobierać te zależności, możesz je buforować, aby przepływ pracy działał szybciej i wydajniej. Buforowanie zależności skraca czas potrzebny na uruchomienie pewnych kroków w przepływie pracy, ponieważ procesy na agentach hostowanych na GitHubie są za każdym razem uruchamiane w czystym środowisku wirtualnym.

Aby buforować zależności dla zadania, użyj akcji usługi GitHub cache . Ta akcja pobiera pamięć podręczną zidentyfikowaną przez określony klucz. Po znalezieniu pamięci podręcznej akcja pobiera buforowane pliki do skonfigurowanej ścieżki. Aby użyć cache akcji, należy ustawić kilka określonych parametrów:

Parametr	Opis	Wymagane
`Key`	Odwołuje się do identyfikatora klucza utworzonego podczas zapisywania i wyszukiwania pamięci podręcznej.	Tak
`Path`	Odwołuje się do ścieżki pliku w module uruchamiającym, aby buforować lub wyszukiwać.	Tak
`Restore-keys`	Składa się z alternatywnych istniejących kluczy do pamięci podręcznej, jeśli żądany klucz pamięci podręcznej nie zostanie znaleziony.	Nie.

steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

W poprzednim przykładzie path parametr jest ustawiony na ~/.npm i key zawiera system operacyjny modułu uruchamiającego oraz skrót package-lock.json SHA-256 pliku. Prefiksowanie klucza o identyfikatorze (npm-cache w tym przykładzie) jest przydatne w przypadku korzystania z rezerwowego restore-keys elementu i wielu pamięci podręcznych.

Przekazywanie danych artefaktu między zadaniami

Podobnie jak w przypadku buforowania zależności w przepływie pracy, można przekazywać dane między zadaniami wewnątrz tego samego przepływu pracy. Dane można przekazywać przy użyciu akcji upload-artifact i download-artifact. Zadania zależne od artefaktów poprzedniego zadania muszą czekać na pomyślne zakończenie poprzedniego zadania, zanim będą mogły zostać uruchomione. Takie podejście jest przydatne, jeśli masz szereg zadań, które muszą być uruchamiane sekwencyjnie na podstawie artefaktów przekazanych z wcześniejszego zadania. Na przykład job_2 wymaga job_1 użycia needs: job_1 składni .

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

W tym przykładzie istnieją dwa zadania. job_1 zapisuje jakiś tekst w file.txt pliku. Następnie używa actions/upload-artifact@v2 akcji do przekazania tego artefaktu i przechowywania danych do użycia w przyszłości w przepływie pracy. job_2 wymaga job_1 ukończenia needs: job_1 przy użyciu składni . Następnie użyje actions/download-artifact@v2 akcji , aby pobrać ten artefakt, a następnie wyświetlić zawartość file.txtelementu .

Włączanie rejestrowania debugowania kroków w przepływie pracy

W niektórych przypadkach domyślne dzienniki przepływu pracy nie zapewniają wystarczającej ilości szczegółów, aby zdiagnozować, dlaczego określone uruchomienie, zadanie lub krok przepływu pracy zakończy się niepowodzeniem. W tych scenariuszach można włączyć bardziej szczegółowe logowanie debugowania dla dwóch opcji: przebiegów i kroków. Włącz to rejestrowanie diagnostyczne, ustawiając dwa wpisy tajne repozytorium, które wymagają dostępu do repozytorium, na admin.

Aby włączyć rejestrowanie diagnostyczne, ustaw tajny klucz w repozytorium zawierającym przepływ pracy na ACTIONS_RUNNER_DEBUG.
Aby włączyć rejestrowanie diagnostyczne kroków, ustaw ACTIONS_STEP_DEBUG wpis tajny w repozytorium zawierający przepływ pracy na true.

Uzyskiwanie dostępu do dzienników przepływu pracy w usłudze GitHub

Jeśli myślisz o pomyślnej automatyzacji, chcesz poświęcić najmniejszą ilość czasu na przyjrzenie się temu, co jest zautomatyzowane, dzięki czemu możesz skupić się na tym, co jest istotne. Ale czasami rzeczy nie idą zgodnie z planem i trzeba przejrzeć, co się stało. Ten proces debugowania może być frustrujący.

Usługa GitHub ma jasny, ustrukturyzowany układ, który ułatwia szybkie przechodzenie między zadaniami, zachowując kontekst bieżącego kroku debugowania.

Aby wyświetlić dzienniki przebiegu przepływu pracy w usłudze GitHub:

W repozytorium przejdź do karty Akcje .
W okienku po lewej stronie wybierz przepływ pracy.
Na liście przebiegów przepływu pracy wybierz przebieg.
W obszarze Zadania wybierz zadanie.
Odczytywanie danych wyjściowych dziennika.

Jeśli masz kilka przebiegów wewnątrz przepływu pracy, możesz wybrać filtr Stan po wybraniu przepływu pracy i ustawić go na Wartość Niepowodzenie , aby wyświetlić tylko przebiegi zakończone niepowodzeniem w tym przepływie pracy.

Uzyskiwanie dostępu do dzienników przepływu pracy z poziomu interfejsu API REST

Oprócz wyświetlania dzienników za pośrednictwem usługi GitHub można użyć interfejsu API REST usługi GitHub do wyświetlania dzienników dla przebiegów przepływu pracy, ponownego uruchamiania przepływów pracy, a nawet anulowania przebiegów przepływu pracy. Aby wyświetlić dziennik przebiegu przepływu pracy przy użyciu interfejsu API, wyślij GET żądanie do punktu końcowego dzienników. Należy pamiętać, że każda osoba mająca dostęp do odczytu do repozytorium może używać tego punktu końcowego. Jeśli repozytorium jest prywatne, musisz użyć tokenu dostępu z zakresem repo .

Na przykład GET żądanie obejrzenia określonego dziennika uruchamiania przepływu pracy przebiega według następującej ścieżki:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

Identyfikowanie, kiedy należy używać tokenu instalacji z aplikacji GitHub

Po zainstalowaniu aplikacji GitHub na koncie możesz ją uwierzytelnić jako instalację aplikacji, korzystając z installation access token dla żądań API REST i GraphQL. Ten krok umożliwia aplikacji dostęp do zasobów należących do instalacji przy założeniu, że aplikacja otrzymała wymagany dostęp do repozytorium i uprawnienia. Żądania interfejsu API REST lub GraphQL wysyłane przez instalację aplikacji są przypisywane do aplikacji.

W poniższym przykładzie zastąp element INSTALLATION_ACCESS_TOKEN tokenem dostępu instalacji:

curl --request GET \
--url "https://api.github.com/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2022-11-28"

Możesz również użyć tokenu dostępu instalacji do uwierzytelniania na potrzeby dostępu do Git opartego na protokole HTTP. Aplikacja musi mieć Contents uprawnienie do repozytorium. Następnie możesz użyć tokenu dostępu instalacji jako hasła HTTP.

W przykładzie zastąp TOKEN tokenem dostępu do instalacji.

git clone https://x-access-token:TOKEN@github.com/owner/repo.git

Sprzężenie zwrotne

Czy ta strona była pomocna?