Lockfile GitHub Actions připíná spouštěný kód, ne celé CI

Lze důvěřovat GitHub Actions, když workflow odkazuje na action pomocí tagu, jako je @v3? Lockfile upřesňuje, který commit action se spustí, i když se tag později přesune. Tým může v diffu kontrolovat aktualizace závislostí a vést ověřitelný seznam actions používaných v CI. Praktická hranice: lockfile pokrývá actions volané v jednotlivých krocích, ale reusable workflow volaný na úrovni jobu je nutné připnout samostatně. Popsaný mechanismus je dostupný v GitHub Enterprise Cloud.

Co přesně lockfile připíná?

Odkazy na větve a tagy jsou praktické, ale verze, na kterou ukazují, se může změnit. Záznam jako uses: octo-org/deploy-action@v3 odkazuje na název tagu; GitHub tento odkaz při spuštění převede na commit. Pokud vlastník projektu tag přesune, další spuštění bez připnuté závislosti může získat jiný kód.

Podle dokumentace GitHubu k lockfile soubor .github/workflows/actions.lock uchovává odkazy na závislosti a odpovídající commit SHA, včetně tranzitivních závislostí — tedy actions, které používají jiné actions. Soubor vytváří rozšíření GitHub CLI gh actions-lock; ručně se neupravuje.

Generátor může také upřesnit odkazy uses v souborech workflow: například změnit odkaz na pohyblivý tag na konkrétnější a zachovat commit, na který odkazoval při vytvoření lockfile. Při zavádění proto zkontrolujte celý diff — změny workflow i lockfile — a ověřte, že připnutá verze je ta, kterou chce tým spouštět.

Aktualizace závislosti se pak projeví jako viditelná změna v repozitáři: tým může změnu commitu zkontrolovat, prodiskutovat a schválit v rámci běžného review. Lockfile pomáhá auditovat kód actions a udržovat konzistentní závislosti; sám o sobě však nepotvrzuje bezpečnost zvoleného kódu.

Kde končí rozsah připínání?

Volání reusable workflow v jobs.<job_id>.uses lockfile repozitáře, který ho volá, nepřipíná. Závislosti reusable workflow patří do repozitáře, v němž je tento workflow definován. Chcete-li připnout samotné volání, uveďte úplný commit SHA; k připnutí jeho actions v původním repozitáři je potřeba vlastní lockfile.

Lockfile kontroluje kód actions, nikoli další vstupy sestavení, například předané parametry, tajné údaje nebo image runneru. Odpovídá na konkrétní otázku: který commit kódu action se spustí? Tyto ostatní prvky vyžadují vlastní pravidla správy.

Výjimkou je lokální action volaný pomocí cesty, jako je uses: ./. Podle pokynů GitHubu rozšíření gh actions-lock lokální cestu k action nepřipíná ani neanalyzuje. Pokud takový action používá jiné actions, je třeba závislosti spravovat samostatně; dokumentace popisuje možnost převést odkazy na lokální actions do formátu $/.

Jediný záznam v lockfile tak může být součástí řetězce, ale nenahrazuje kontrolu všech jeho článků. U externího reusable workflow ověřte připnutí volání i stav zdrojového repozitáře; u lokálních actions zkontrolujte, jak jsou započítány jejich závislosti.

Jak zavést kontrolu bez nečekaného zastavení CI?

GitHub doporučuje nejprve provést pilotní nasazení ve vybraných repozitářích a workflow. Politika Require lockfile zablokuje spuštění cílových workflow bez platného lockfile, včetně workflow bez závislostí uses:. Režim Evaluate pro politiky je dostupný pouze v GitHub Enterprise Cloud. Nejdříve proto připravte rozsah a automatické aktualizace a teprve potom zapněte povinné pravidlo.

1. Zkontrolujte původní odkazy. Před vytvořením lockfile ověřte, že actions odkazují na verze, které chce tým skutečně připnout. Generátor připne commit určený z aktuálního odkazu.
2. Vytvořte lockfile a zkontrolujte ho. Nainstalujte rozšíření gh-actions-lock, spusťte gh actions-lock v kořenovém adresáři repozitáře a prohlédněte si celý diff včetně přepsaných odkazů uses.
3. Nastavte aktualizace a ověřování. Dependabot může aktualizovat odpovídající záznamy pro již připojené workflow. V CI lze v pull requestu nastavit kontrolní úlohu s příkazem gh actions-lock --verify, která odhalí zastaralý lockfile ještě před hlavním sestavením.
4. Určete schvalovatele. Přidejte .github/workflows/actions.lock do CODEOWNERS a vyžadujte kontrolu změn od osob odpovědných za bezpečnost sestavení.
5. Proveďte pilot politiky. Začněte s připojenými repozitáři a workflow. V režimu Evaluate analyzujte výsledky; před přepnutím do režimu Active ověřte, že jsou připraveny všechny cílové workflow a lockfiles jsou aktuální.

Require lockfile a samostatná politika Require actions to be pinned to a full-length commit SHA jsou různá pravidla; GitHub uvádí, že mohou platit současně. Kontrola v CI a povinná politika mají také odlišné role: první odhalí zastaralý soubor při práci na pull requestu, druhá zablokuje spuštění workflow, které požadavku nevyhovuje.

Příklad: aktualizace deployment action

Předpokládejme, že workflow publikuje aplikaci pomocí octo-org/deploy-action@v3. Tým nejprve ověří, jakou verzi tento odkaz určuje, poté spustí gh actions-lock a prohlédne si diff workflow spolu se záznamem commitu v lockfile. Při aktualizaci action kontrolující vidí změny odkazů i připnutého commitu; může tak posoudit konkrétní aktualizaci, místo aby spoléhal na to, že pohyblivý tag vždy ukazuje na stejný kód.

Pokud deployment provádí reusable workflow z jiného repozitáře, místní lockfile jeho závislosti nepokrývá. Připněte odkaz na reusable workflow úplným SHA a ověřte, že zdrojový repozitář spravuje vlastní závislosti actions. Ve velkých organizacích se tím roztříštěná pravidla mění na ověřitelný proces, přičemž parametry, tajné údaje a runner zůstávají pod samostatnou kontrolou.

Lockfile je užitečnou vrstvou kontroly kódu actions: zpřehledňuje verze a aktualizace, včetně tranzitivních závislostí. Chcete-li zajistit spolehlivé pokrytí, zkontrolujte také reusable workflows a lokální actions, automatizujte aktualizace a povinnou politiku zavádějte až po pilotním nasazení.