Přizpůsobení pracovního postupu pomocí proměnných prostředí a dat artefaktů

12 min

Tady se dozvíte, jak používat výchozí a vlastní proměnné prostředí, vlastní skripty, závislosti mezipaměti a předávat data artefaktů mezi úlohami. Dozvíte se také, jak získat přístup k protokolům pracovního postupu z webu GitHubu i z koncových bodů rozhraní REST API.

Výchozí proměnné prostředí a kontexty

V pracovním postupu GitHub Actions je k dispozici několik výchozích proměnných prostředí, které můžete použít, ale pouze v rámci spouštěče, který spouští úlohu. Tyto výchozí proměnné rozlišují malá a velká písmena a odkazují na hodnoty konfigurace systému a aktuálního uživatele. Tyto výchozí proměnné prostředí doporučujeme použít k odkazování na systém souborů místo použití pevně zakódovaných cest k souborům. Pokud chcete použít výchozí proměnnou prostředí, zadejte $ název proměnné prostředí.

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

Kromě výchozích proměnných prostředí můžete jako kontexty použít definované proměnné. Kontexty a výchozí proměnné jsou podobné v tom, že obě poskytují přístup k informacím o prostředí, ale mají některé důležité rozdíly. Výchozí proměnné prostředí lze použít pouze v rámci spouštěče, kontextové proměnné lze použít v libovolném bodě pracovního postupu. Kontextové proměnné například umožňují spustit if příkaz pro vyhodnocení výrazu před spuštěním spouštěče.

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"

Tento příklad používá github.ref kontext ke kontrole větve, která aktivovala pracovní postup. Pokud je mainvětev , spustí se spouštěč a vypíše "Nasazení na produkční server na větvi $GITHUB_REF". Výchozí proměnná $GITHUB_REF prostředí se ve spouštěči používá k odkazování na větev. Všimněte si, že výchozí proměnné prostředí jsou velkými písmeny, kde jsou všechny kontextové proměnné malými písmeny.

Vlastní proměnné prostředí

Podobně jako při použití výchozích proměnných prostředí můžete v souboru pracovního postupu použít vlastní proměnné prostředí. Pokud chcete vytvořit vlastní proměnnou, musíte ji definovat v souboru pracovního postupu pomocí env kontextu. Pokud chcete použít hodnotu proměnné prostředí uvnitř spouštěče, můžete pro čtení proměnných prostředí použít normální metodu operačního systému Runner.

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

Skripty v pracovním postupu

V předchozích příkladech run fragmentů pracovního postupu se klíčové slovo používá k jednoduchému tisku řetězce textu. run Vzhledem k tomu, že klíčové slovo dává úloze pokyn ke spuštění příkazu na spouštěči, použijete run klíčové slovo ke spuštění akcí nebo skriptů.

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

V tomto příkladu používáte npm k instalaci bats balíčku pro testování softwaru pomocí klíčového run slova. Skript můžete také spustit jako akci. Skript můžete uložit do úložiště, často provedené v .github/scripts/ adresáři, a pak zadat cestu a typ prostředí pomocí klíčového run slova.

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

Závislosti mezipaměti pomocí akce mezipaměti

Při vytváření pracovního postupu často zjistíte, že potřebujete opakovaně používat stejné výstupy nebo stahovat závislosti z jednoho spuštění do druhého. Místo opětovného stažení těchto závislostí je můžete uložit do mezipaměti, aby pracovní postup běžel rychleji a efektivněji. To může výrazně zkrátit dobu potřebnou ke spuštění určitých kroků v pracovním postupu, protože úlohy na spouštěčích hostovaných na GitHubu se pokaždé spouštějí v čistém virtuálním prostředí. Ukládání do mezipaměti závislostí vám pomůže urychlit dobu potřebnou k opětovnému vytvoření těchto souborů závislostí.

K ukládání závislostí úlohy do mezipaměti použijte akci GitHubu cache . Tato akce načte mezipaměť identifikovanou jedinečným klíčem, který zadáte. Když akce najde mezipaměť, načte soubory uložené v mezipaměti do cesty, kterou nakonfigurujete. Pokud chcete akci použít cache , budete muset nastavit několik konkrétních parametrů:

Parametr	Popis	Povinní účastníci
Key	Odkazuje na identifikátor klíče vytvořený při ukládání a hledání mezipaměti.	Ano
Cesta	Odkazuje na cestu k souboru ve spouštěči pro ukládání do mezipaměti nebo vyhledávání.	Ano
Obnovení klíčů	obsahuje alternativní existující klíče k mezipaměti, pokud se požadovaný klíč mezipaměti nenajde.	No

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-

V předchozím příkladu je nastavená path~/.npm hodnota a key zahrnuje operační systém spouštěče a hodnotu hash package-lock.json SHA-256 souboru. Předpona klíče s ID (npm-cache v tomto příkladu restore-keys ) je užitečná, když používáte náhradní klíč a máte více mezipamětí.

Předávání dat artefaktů mezi úlohami

Podobně jako v případě ukládání závislostí do mezipaměti v rámci pracovního postupu můžete předávat data mezi úlohami v rámci stejného pracovního postupu. Můžete to provést pomocí akcí upload-artifact a download-artifact akcí. Úlohy, které jsou závislé na artefaktech předchozí úlohy, musí před spuštěním počkat na úspěšné dokončení předchozí úlohy. To je užitečné, pokud máte řadu úloh, které je potřeba spouštět postupně na základě artefaktů nahraných z předchozí úlohy. Například job_2 vyžaduje job_1 použití needs: job_1 syntaxe.

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

Předchozí příklad obsahuje dvě úlohy. job_1 zapíše do souboru file.txt nějaký text a pak pomocí actions/upload-artifact@v2 akce nahraje tento artefakt a uloží data pro budoucí použití v rámci pracovního postupu. job_2 vyžaduje job_1 dokončení pomocí needs: job_1 syntaxe, pak pomocí actions/download-artifact@v2 akce stáhnout tento artefakt a pak vytisknout obsah file.txt.

Povolení protokolování ladění kroku v pracovním postupu

V některýchpřípadechch V těchto situacích můžete povolit další protokolování ladění pro dvě možnosti: spuštění a kroky. Povolte toto protokolování diagnostiky nastavením dvou tajných kódů úložiště, které vyžadují admin přístup k úložišti:true

Pokud chcete povolit protokolování diagnostiky spouštěče, nastavte ACTIONS_RUNNER_DEBUG tajný kód v úložišti, které obsahuje pracovní postup true.
Chcete-li povolit protokolování diagnostiky kroku, nastavte ACTIONS_STEP_DEBUG tajný klíč v úložišti, které obsahuje pracovní postup na true.

Přístup k protokolům pracovního postupu z uživatelského rozhraní

Když uvažujete o úspěšné automatizaci, snažte se věnovat nejméně času tomu, co je automatizované, abyste se mohli zaměřit na to, co je relevantní. Někdy ale věci nejdou podle plánu a potřebujete zkontrolovat, co se stalo. Tento proces ladění může být frustrující, ale GitHub poskytuje jasnou strukturu rozložení, která umožňuje rychlý způsob navigace mezi úlohami a zachování kontextu aktuálně ladicího kroku. Pokud chcete zobrazit protokoly spuštění pracovního postupu na GitHubu, můžete postupovat takto:

V úložišti přejděte na kartu Akce .
Na levém bočním panelu klikněte na požadovaný pracovní postup.
V seznamu spuštění pracovního postupu vyberte požadované spuštění.
V části Úlohy vyberte požadovanou úlohu.
Přečtěte si výstup protokolu.

Pokud máte v rámci pracovního postupu několik spuštění, můžete po výběru pracovního postupu vybrat také filtr stavu a nastavit ho na Hodnotu Selhání tak, aby se zobrazovala pouze neúspěšná spuštění v rámci daného pracovního postupu.

Přístup k protokolům pracovního postupu z rozhraní REST API

Kromě zobrazení protokolů pomocí GitHubu můžete také použít rozhraní REST API GitHubu k zobrazení protokolů pro spuštění pracovního postupu, opětovnému spuštění pracovních postupů nebo dokonce zrušení spuštění pracovního postupu. Pokud chcete zobrazit protokol spuštění pracovního postupu pomocí rozhraní API, musíte odeslat GET požadavek do koncového bodu protokolů. Mějte na paměti, že tento koncový bod může používat každý, kdo má k úložišti přístup pro čtení. Pokud je úložiště privátní, musíte použít přístupový token s oborem repo .

Například GET požadavek na zobrazení konkrétního protokolu spuštění pracovního postupu by postupoval podle této cesty:

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

Pokračovat