Dostosowywanie przepływu pracy za pomocą zmiennych środowiskowych i danych artefaktów

Ukończone

W tym miejscu dowiesz się, jak używać domyślnych i niestandardowych zmiennych środowiskowych, skryptów niestandardowych, zależności pamięci podręcznej i przekazywania danych artefaktu między zadaniami. Dowiesz się również, jak uzyskać dostęp do dzienników przepływu pracy zarówno z witryny internetowej GitHub, jak i punktów końcowych interfejsu API REST.

Domyślne zmienne środowiskowe i konteksty

W przepływie pracy funkcji GitHub Actions istnieje kilka domyślnych zmiennych środowiskowych, które są dostępne do użycia, ale tylko w module uruchamiającym zadanie. Te zmienne domyślne są wrażliwe na wielkość liter i odnoszą się do wartości konfiguracji systemu i bieżącego użytkownika. Zalecamy używanie tych domyślnych zmiennych środowiskowych do odwoływania się do systemu plików, a nie używania zakodowanych na sztywno ścieżek plików. Aby użyć domyślnej zmiennej środowiskowej, określ $ nazwę zmiennej środowiskowej.

jobs:
  prod-check:
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

Oprócz domyślnych zmiennych środowiskowych można użyć zdefiniowanych zmiennych jako kontekstów. Konteksty i zmienne domyślne są podobne, ponieważ zapewniają dostęp do informacji o środowisku, ale mają pewne istotne różnice. Mimo że domyślne zmienne środowiskowe mogą być używane tylko w module uruchamiającym, zmienne kontekstowe mogą być używane w dowolnym momencie przepływu pracy. Na przykład zmienne kontekstowe umożliwiają uruchamianie if instrukcji w celu obliczenia wyrażenia przed wykonaniem modułu uruchamiającego.

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

W tym przykładzie github.ref używany jest kontekst do sprawdzania gałęzi, która wyzwoliła przepływ pracy. Jeśli gałąź to main, moduł uruchamiający jest wykonywany i wyświetla komunikat "Wdrażanie na serwerze produkcyjnym w gałęzi $GITHUB_REF". Domyślna zmienna środowiskowa $GITHUB_REF jest używana w module uruchamiającym odwołania do gałęzi. Zwróć uwagę, że domyślne zmienne środowiskowe są wielkimi literami, w których wszystkie zmienne kontekstowe są małymi literami.

Niestandardowe zmienne środowiskowe

Podobnie jak w przypadku używania domyślnych zmiennych środowiskowych, możesz użyć niestandardowych zmiennych środowiskowych w pliku przepływu pracy. Aby utworzyć zmienną niestandardową, należy zdefiniować ją w pliku przepływu pracy przy użyciu env kontekstu. Jeśli chcesz użyć wartości zmiennej środowiskowej wewnątrz modułu uruchamiającego, możesz użyć normalnej metody systemu operacyjnego modułu uruchamiającego do odczytywania zmiennych środowiskowych.

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Nice work, $First_Name. Deploying to production server on branch $GITHUB_REF"
        env:
          First_Name: Mona

Skrypty w przepływie pracy

W poprzednich przykładach run fragmentów kodu przepływu pracy słowo kluczowe jest używane do zwykłego drukowania ciągu tekstu. run Ponieważ słowo kluczowe nakazuje zadaniu wykonanie polecenia w module uruchamiającym, słowo kluczowe służy run do uruchamiania akcji lub skryptów.

jobs:
  example-job:
    steps:
      - run: npm install -g bats

W tym przykładzie używasz narzędzia npm do zainstalowania bats pakietu testowania oprogramowania przy użyciu słowa kluczowego run . Możesz również uruchomić skrypt jako akcję. Skrypt można przechowywać w repozytorium, często wykonywany w .github/scripts/ katalogu, a następnie podać ścieżkę i typ powłoki przy użyciu słowa kluczowego run .

jobs:
  example-job:
    steps:
      - name: Run build script
        run: ./.github/scripts/build.sh
        shell: bash

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

Podczas kompilowania przepływu pracy często okazuje się, że konieczne jest ponowne użycie tych samych danych wyjściowych lub pobranie 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. Może to znacznie skrócić czas potrzebny na uruchomienie pewnych kroków w przepływie pracy, ponieważ zadania w modułach uruchamianych w usłudze GitHub są uruchamiane w czystym środowisku wirtualnym za każdym razem. Buforowanie zależności pomoże przyspieszyć czas ponownego tworzenia tych plików zależności.

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 Wymagania
Klucz Odwołuje się do identyfikatora klucza utworzonego podczas zapisywania i wyszukiwania pamięci podręcznej. Tak
Ścieżka Odwołuje się do ścieżki pliku w module uruchamiającym, aby buforować lub wyszukiwać. Tak
Przywracanie kluczy program 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 w ramach tego samego przepływu pracy. Można to zrobić za pomocą upload-artifact akcji 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. Jest to przydatne, jeśli masz szereg zadań, które muszą być uruchamiane sekwencyjnie na podstawie artefaktów przekazanych z poprzedniego 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 poprzednim przykładzie istnieją dwa zadania. job_1 Zapisuje jakiś tekst w pliku file.txt , a 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 wykonania przy użyciu needs: job_1 składni , a następnie używa actions/download-artifact@v2 akcji do pobrania tego artefaktu, a następnie wydrukuj zawartość file.txt.

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

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

  • Aby włączyć rejestrowanie diagnostyczne modułu uruchamiającego, ustaw ACTIONS_RUNNER_DEBUG wpis tajny w repozytorium zawierający przepływ pracy na truewartość .
  • 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 z interfejsu użytkownika

Jeśli myślisz o udanej automatyzacji, chcesz poświęcić najmniejszą ilość czasu na przyjrzenie się temu, co jest zautomatyzowane, aby skupić uwagę 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, ale usługa GitHub udostępnia wyraźną strukturę układu, która umożliwia szybki sposób nawigowania między zadaniami przy zachowaniu kontekstu aktualnie debugowania kroku. Aby wyświetlić dzienniki przebiegu przepływu pracy w usłudze GitHub, możesz wykonać następujące kroki:

  1. Przejdź do karty Akcje w repozytorium.
  2. Na pasku bocznym po lewej stronie kliknij żądany przepływ pracy.
  3. Z listy przebiegów przepływu pracy wybierz żądany przebieg.
  4. W obszarze Zadania wybierz żądane zadanie.
  5. Odczytywanie danych wyjściowych dziennika.

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

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

Oprócz wyświetlania dzienników przy użyciu usługi GitHub można również 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, musisz wysłać 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 wyświetlenia określonego dziennika uruchamiania przepływu pracy będzie miało następującą ścieżkę:

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