Dostosowywanie przepływu pracy za pomocą zmiennych środowiskowych i danych artefaktów
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 natrue
wartość . - Aby włączyć rejestrowanie diagnostyczne kroków, ustaw
ACTIONS_STEP_DEBUG
wpis tajny w repozytorium zawierający przepływ pracy natrue
.
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:
- Przejdź do karty Akcje w repozytorium.
- Na pasku bocznym po lewej stronie kliknij żądany przepływ pracy.
- Z listy przebiegów przepływu pracy wybierz żądany przebieg.
- W obszarze Zadania wybierz żądane zadanie.
- 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