Ukládat do mezipaměti, sdílet a ladit pracovní postupy

8 min

V této lekci se dozvíte, jak optimalizovat výkon, předávat data mezi úlohami a řešit potíže s pracovními postupy pomocí protokolů a tokenů.

Pokud chcete tento proces implementovat, naučíte se:

Závislosti mezipaměti pro rychlejší pracovní postupy
Předání dat artefaktů mezi úlohami
Povolte protokolování ladění pro pracovní postupy.
Přístup k protokolům pracovního postupu z uživatelského rozhraní GitHubu a rozhraní REST API
Použijte instalační tokeny pro ověřování aplikací GitHubu.

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

Při vytváření pracovního postupu často 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. Ukládání závislostí do mezipaměti zkracuje 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í.

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. Chcete-li použít akci cache, musíte nastavit několik konkrétních parametrů.

Parametr	Popis	Povinné
`Key`	Odkazuje na identifikátor klíče vytvořený při ukládání a hledání mezipaměti.	Ano
`Path`	Odkazuje na cestu k souboru ve spouštěči pro ukládání do mezipaměti nebo vyhledávání.	Ano
`Restore-keys`	Pokud se požadovaný klíč mezipaměti nenajde, skládá se z alternativních existujících klíčů, které se mají ukládat do mezipaměti.	Ne

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 záložní klíč a máte více mezipamětí.

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

Podobně jako u myšlenky ukládání závislostí do mezipaměti v rámci pracovního postupu můžete předávat data mezi úlohami uvnitř stejného pracovního postupu. Data můžete předat pomocí akcí upload-artifact a download-artifact. Ú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. Tento přístup 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

Tento příklad obsahuje dvě úlohy. job_1 zapíše nějaký text v file.txt souboru. 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. Potom pomocí actions/download-artifact@v2 akce stáhne tento artefakt a pak vytiskne obsah file.txt.

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

V některých případech výchozí pracovní protokoly neposkytují dostatek podrobností k diagnostice, proč určitý běh, úloha nebo krok pracovního postupu selhal. V těchto scénářích můžete povolit podrobné protokolování ladění týkající se dvou položek: spuštění a kroky. Povolte toto diagnostické protokolování nastavením dvou tajemství úložiště, která vyžadují admin přístup k úložišti true.

Chcete-li povolit protokolování diagnostiky, nastavte ACTIONS_RUNNER_DEBUG tajný klíč v úložišti, které obsahuje pracovní postup na 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 na GitHubu

Když uvažujete o úspěšné automatizaci, snažte se věnovat nejméně času tomu, co je automatizované, abyste se mohli soustředit 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í.

GitHub má jasné strukturované rozložení, které vám pomůže rychle přecházet mezi úlohami a zachovat kontext aktuálního kroku ladění.

Zobrazení protokolů spuštění pracovního postupu na GitHubu:

V úložišti přejděte na záložku Akce.
V levém podokně vyberte pracovní postup.
V seznamu spuštění pracovního postupu vyberte spuštění.
V části Úlohy vyberte úlohu.
Přečtěte si výstup protokolu.

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

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

Kromě zobrazení protokolů prostřednictvím GitHubu můžete pomocí rozhraní REST API GitHubu zobrazit protokoly pro spuštění pracovního postupu, spustit pracovní postupy znovu nebo dokonce zrušit spuštění pracovního postupu. Pokud chcete zobrazit protokol spuštění pracovního postupu pomocí rozhraní API, odešlete 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 se řídí touto cestou:

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

Určení, kdy použít instalační token z aplikace GitHub

Když je vaše aplikace GitHub nainstalovaná na účtu, můžete ji ověřit jako instalaci aplikace pomocí installation access token požadavků rozhraní REST a GraphQL API. Tento krok umožňuje aplikaci přistupovat k prostředkům vlastněným instalací za předpokladu, že aplikaci byl udělen požadovaný přístup k úložišti a oprávnění. Požadavky rozhraní REST nebo GraphQL API vytvořené instalací aplikace jsou přiřazeny aplikaci.

V následujícím příkladu nahradíte INSTALLATION_ACCESS_TOKEN přístupovým tokenem instalace:

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"

K ověření přístupu ke Git založeného na protokolu HTTP můžete také použít instalační token. Vaše aplikace musí mít oprávnění úložiště Contents . Přístupový token instalace pak můžete použít jako heslo HTTP.

V příkladu nahradíte TOKEN přístupovým tokenem instalace:

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

Váš názor

Byla tato stránka užitečná?