Správa a ladění pracovních postupů v GitHub Actions

10 min

Vzpomeňte si, že vaším cílem je automatizovat proces sestavení a publikování kódu, aby se funkce aktualizovaly pokaždé, když vývojář přidá změnu do základu kódu.

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

Identifikujte událost, která aktivovala pracovní postup.
Použijte protokoly pracovního postupu GitHub Actions.
Uložte artefakty sestavení a získejte k němu přístup.
Automatizujte přidání štítku do pull requestu po kontrole.

Identifikace události, která aktivovala pracovní postup

Pochopení toho, co aktivovalo pracovní postup GitHub Actions, je zásadní pro ladění, auditování a vylepšování kanálů CI/CD. Typy spouštěčů zahrnují push do větve, vytvoření nebo aktualizace žádosti o přijetí změn, naplánovanou úlohu nebo ruční spuštění. Aktivační událost můžete identifikovat tak, že prozkoumáte spuštění pracovního postupu, změny úložiště a související problém gitHubu nebo žádost o přijetí změn.

Diagram znázorňující různé triggery pracovního postupu v GitHub Actions, jako jsou nabízení, žádost o přijetí změn, plán a ruční odeslání

Co je trigger pracovního postupu?

Trigger pracovního postupu je událost, která způsobí spuštění pracovního postupu. GitHub podporuje různé typy triggerů, mezi které patří:

push nebo pull_request (na základě změn kódu)
workflow_dispatch (ruční spouštěč)
schedule (úlohy cron)
repository_dispatch (externí systémy)
Události problému, diskuze a žádosti o přijetí změn (například issues.opened, pull_request.closed)

Identifikace spouštěcí události

Událost triggeru pracovního postupu můžete identifikovat několika způsoby:

Použijte uživatelské rozhraní GitHub Actions:
1. V úložišti vyberte kartu Akce .
2. Vyberte spuštění pracovního postupu.
V horní části souhrnu spuštění pracovního postupu se zobrazí typ události, například push, pull_request nebo workflow_dispatch.
Používá se github.event_name v protokolech nebo v pracovním postupu.
- GitHub zveřejňuje kontextová data během spuštění pracovního postupu. Proměnná github.event_name vám řekne, která událost aktivovala pracovní postup.
- Informace můžete vytisknout v rámci procesu ladění pro účely debugování.
```
-name: Show event trigger
  run: echo "Triggered by ${{ github.event_name }}"
```
Použijte podrobnosti o spuštění pracovního postupu:
- Pokud zkoumáte běhy pracovního postupu programově, například pomocí rozhraní API, objekt event obsahuje vlastnost určující spouštěcí událost.
- Můžete najít algoritmus SHA (Secure Hash Algorithm), aktéra a časové razítko, abyste zjistili, co způsobilo aktivaci.

Odvození triggeru z efektů úložiště

Možná nemáte přímý přístup ke spuštění pracovního postupu, ale přesto chcete odvodit, co aktivovalo spuštění pracovního postupu na základě aktivity úložiště:

Pozorované chování	Aktivační událost
Do `main` byl nahrán nový commit a pracovní postup byl spuštěn.	událost `push`
Požadavek na stažení byl otevřen nebo aktualizován.	událost `pull_request`
Přispěvatel spustil pracovní postup ručně.	`workflow_dispatch`
Pracovní postup se spouští každý den v určitém čase.	`schedule` (cron)
Pracovní postup se spustil po volání externí služby.	`repository_dispatch`
Pracovní postup se spustil při přidání popisku nebo komentáře k problému.	událost `issues.*`

Kontrolou časových značek, aktivity pull requestů a historie commitů můžete často určit, jaká akce způsobila spuštění pracovního postupu.

Shrnutí toho, jak identifikovat, co aktivovalo pracovní postup:

Na kartě Akce zkontrolujte souhrn spuštění pracovního postupu.
Vytiskněte nebo zalogujte github.event_name uvnitř pracovního postupu pro lepší viditelnost.
Porovnejte časová razítka a aktivitu úložiště (potvrzení, žádosti o přijetí změn, problémy) a odvozujte trigger.
Úplný event kontext použijte k hlubšímu zkoumání.

Tyto postupy vám pomůžou ladit, auditovat a zlepšovat spolehlivost pracovních postupů napříč kanály vývoje a nasazení.

Vysvětlení účinku pracovního postupu čtením konfiguračního souboru

Abyste pochopili účinky pracovního postupu z jeho konfiguračního souboru, analyzujte strukturu a obsah souboru .yml uloženého v .github/workflows/.

Konfigurační soubor pracovního postupu určuje následující informace o pracovním postupu:

Když se spustí (v sekci on ).
Co to dělá (v jobs a steps).
Kde se spouští (část runs-on).
Proč běží (jeho účel, například testování, nasazení nebo lintování).
Jak se chová v konkrétních podmínkách (prostředí, filtry, logika).

Interpretace efektu pracovního postupu

Identifikujte spouštěč.

Pokud chcete zjistit, jaká akce pracovní postup iniciovala, přečtěte si on část pracovního postupu.

Například:
```
on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:
```
Tento ukázkový pracovní postup:
- Spustí se automaticky, když je kód odeslán do hlavní větve (push).
- Spustí se při vytvoření nebo aktualizaci žádosti o přijetí změn (pull_request).
- Může být aktivováno uživatelem ručně (workflow_dispatch).
Identifikujte úlohy a kroky pracovního postupu.

Informace o tom, co pracovní postup dělá, najdete v jobssteps částech pracovního postupu.

Například:
```
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
```
Tento ukázkový pracovní postup:
- Používá virtuální prostředí s Linuxem (runs-on).
- Zkontroluje kód úložiště (steps>name).
- Nainstaluje závislosti projektu (steps>name).
- Spouští automatizované testy (steps>name).
Vyhodnoťte účel a výsledek pracovního postupu.

Přečtením konfiguračního souboru můžete popsat zamýšlený výsledek pracovního postupu:

Tento pracovní postup je kanál kontinuální integrace (CI). Zajišťuje, aby se automaticky otestoval jakýkoli nový kód, který byl odeslán do úložiště nebo podán prostřednictvím požadavku na přijetí změn. Pokud testy selžou, uživatelské rozhraní pracovního postupu GitHubu zobrazí tento výsledek, který vám pomůže udržet kvalitu kódu."
Identifikujte nebo nastavte volitelné funkce, které ovlivňují způsob spuštění pracovního postupu:
- env nastaví proměnné prostředí.
- if přidá podmíněnou logiku ke spuštění konkrétních kroků pouze v případech, kdy jsou splněna kritéria.
- timeout-minutes nebo continue-on-error nastavte provádění pracovního postupu a zpracování chyb.

Diagnostika neúspěšného spuštění pracovního postupu

V úložišti přejděte na záložku Akce.
Vyhledejte neúspěšné spuštění (obvykle to označuje červený symbol X).
Výběrem neúspěšného pracovního postupu otevřete souhrn běhu.
V protokolech pracovního postupu zkontrolujte chybu.
1. Ve souhrnu spuštění rozbalte každý úkol a krok, dokud nenajdete ten, který naznačuje chybu.
2. Vyberte úlohu nebo krok a zobrazte její protokoly.
3. Hledat:
  - Chybové zprávy
  - Trasování zásobníku
  - Ukončovací kódy
Například neúspěšný test může zobrazit npm ERR! Test failed nebo exit code 1.
Zkontrolujte konfigurační soubor pracovního postupu.

Použijte soubor .yml k určení:
- Co se jednotlivé kroky snažily udělat?
- Pokud existují proměnné prostředí (env) nebo podmíněné podmínky (if), které ovlivňují provádění.
- Pokud příčinou selhání je chybějící závislost, chyba syntaxe nebo chybně nakonfigurovaný krok.
Pokud krok selže, zkontrolujte následující příčiny:
- Byly závislosti úspěšně nainstalovány v předchozím kroku?
- Existují testovací soubory a předávají se místně?

Běžné scénáře selhání

Následující tabulka popisuje běžné scénáře selhání pracovního postupu:

Příznaky	Pravděpodobná příčina
Operace selže a vrátí `command not found`l	Chybějící závislost nebo nesprávné nastavení
`npm install` selhává.	Problém s poškozeným `package-lock.json` souborem nebo sítí
Testovací krok selže.	Problémy s testováním částí, chybějící konfigurační soubor nebo neplatná syntaxe testu
`Permission denied` se zobrazí.	Nesprávná oprávnění k souborům nebo chybějící tajné kódy

Určení přístupu k protokolům pracovního postupu na GitHubu

V úložišti přejděte na záložku Akce.
V seznamu pracovních postupů vyberte příslušný pracovní postup.

Pokud má například soubor .yml následující kód, zobrazí se v seznamu odkaz s názvem PRACOVNÍ postup CI :
```
name: CI Workflow
```
Vyberte konkrétní běh.

V seznamu spuštění, která zobrazují stav, vyberte časové razítko nebo potvrzovací zprávu konkrétního spuštění, které chcete zkontrolovat.
Rozšiřte každou úlohu a jednotlivé kroky.

Na stránce souhrnu spuštění se zobrazí úlohy, které jsou definované v souboru pracovního postupu, například sestavení nebo testování:
1. Vyberte úlohu, kterou chcete rozbalit.
2. V rámci úlohy rozbalte jednotlivé kroky, například Instalovat závislosti nebo Spustit testy.
Zobrazení výstupu protokolu

Pokud chcete zobrazit úplný výstup protokolu, včetně protokolů konzoly, chybových zpráv a informací o ladění, vyberte krok pracovního postupu. Protokoly můžete kopírovat, vyhledávat a stahovat.

Následující tabulka shrnuje kroky, které provedete pro přístup k protokolům pracovního postupu:

Činnost	Účel
Karta akcí	Zobrazit všechna spuštění pracovního postupu
Vyberte název pracovního postupu.	Filtr se spouští podle pracovního postupu.
Výběr spuštění	Podívejte se na konkrétní výsledky úlohy a kroku.
Rozbalit kroky	Prohlédněte si podrobné protokoly.
Stažení protokolů	Stáhněte si protokoly pro offline řešení potíží nebo pro týmové řešení potíží.

Záznamy činností pro sestavení

Když se pracovní postup spustí, vytvoří protokol, který obsahuje podrobnosti o tom, co se stalo, a případné chyby nebo selhání testů.

Pokud dojde k chybě nebo pokud test selže, zobrazí se v protokolech červený symbol X místo zelené značky zaškrtnutí. Můžete prozkoumat podrobnosti o chybě nebo selhání a zjistit, co se stalo.

Snímek obrazovky s logem GitHub Actions, s podrobnostmi o neúspěšném testu.

Práce s artefakty

Když pracovní postup vytvoří něco jiného než záznam protokolu, produkt se nazývá artefakt. Například sestavení Node.js vytvoří kontejner Dockeru, který je možné nasadit. Kontejner je artefakt, který můžete nahrát do úložiště pomocí akce actions/upload-artifact. Artefakt si později můžete stáhnout z úložiště pomocí akcí nebo stažení artefaktu.

Uložení artefaktu ho zachová mezi úlohami. Každá úloha používá novou instanci virtuálního počítače, takže artefakt nemůžete znovu použít tak, že ho uložíte na virtuální počítač. Pokud artefakt potřebujete v jiné úloze, můžete artefakt nahrát do úložiště v jedné úloze a stáhnout ho pro jinou úlohu.

Úložiště artefaktů

Artefakty se ukládají do prostoru úložiště na GitHubu. Místo je zdarma pro veřejná úložiště a některé úložiště jsou zdarma pro privátní úložiště v závislosti na účtu. GitHub ukládá artefakty po dobu 90 dnů.

V následujícím fragmentu kódu pracovního postupu si všimněte, že v akci actions/upload-artifact@main existuje atribut path. Hodnota tohoto atributu je cesta k uložení artefaktu. V tomto příkladu zadáte veřejné/ pro nahrání všeho do adresáře. Pokud chcete nahrát jenom jeden soubor, použijte něco jako veřejné/mytext.txt.

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@main
        with:
          name: webpack artifacts
          path: public/

Pokud chcete stáhnout artefakt pro testování, musí se sestavení úspěšně dokončit a nahrát artefakt. V následujícím kódu určíte, že testovací úloha závisí na úloze sestavení.

test:
    needs: build
    runs-on: ubuntu-latest

V následujícím fragmentu kódu pracovního postupu stáhnete artefakt. Teď může testovací úloha použít artefakt k testování.

steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public

Další informace o používání artefaktů v pracovních postupech najdete v tématu Ukládání dat pracovního postupu jako artefaktů.

Automatizace kontrol na GitHubu pomocí pracovních postupů

Kromě spuštění pracovního postupu prostřednictvím událostí GitHubu, jako jsou push a pull-request, můžete pracovní postup spustit podle plánu nebo po nějaké události mimo GitHub.

Možná budete chtít, aby se pracovní postup spustil až po dokončení konkrétní akce, například pokud revidující schválí pull request. Pro tento scénář můžete aktivovat pull-request-review.

Další akcí, kterou můžete provést, je přidání štítku k pull requestu. V tomto případě použijte akci pullreminders/label-when-approved-action.

Například:

    steps:
     - name: Label when approved
       uses: pullreminders/label-when-approved-action@main
       env:
         APPROVALS: "1"
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         ADD_LABEL: "approved"

env V bloku nastavíte proměnné prostředí pro akci. Můžete například nastavit počet schvalovatelů potřebných ke spuštění pracovního postupu. V tomto příkladu je to jedna. Ověřovací proměnná secrets.GITHUB_TOKEN je povinná, protože akce musí provádět změny v úložišti přidáním popisku. Nakonec zadáte název popisku, který chcete přidat.

Přidání popisku může být událost, která spustí jiný pracovní postup, například sloučení. Tuto událost probereme v dalším modulu, který popisuje použití průběžného doručování v GitHub Actions.

Váš názor

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