GitHub Actions-låsfilen låser körningskoden, men inte hela CI

Går det att lita på GitHub Actions om ett arbetsflöde hänvisar till en action med en tagg som @v3? Låsfilen anger vilken commit av actionen som ska köras, även om taggen senare flyttas. Teamet kan granska beroendeuppdateringar i diffen och föra en kontrollerbar lista över de actions som CI använder. En praktisk begränsning är att låsfilen omfattar actions som anropas i steg, medan ett återanvändbart arbetsflöde som anropas på jobbnivå måste låsas separat. Den beskrivna mekanismen är tillgänglig i GitHub Enterprise Cloud.

Vad är det låsfilen faktiskt låser?

Hänvisningar till grenar och taggar är praktiska, men den version de pekar på kan ändras. En post som uses: octo-org/deploy-action@v3 anger en tagg; GitHub löser upp hänvisningen till en commit när arbetsflödet körs. Om projektets ägare flyttar taggen kan nästa körning, utan ett låst beroende, få annan kod.

Enligt GitHubs dokumentation om låsfiler lagrar filen .github/workflows/actions.lock beroendehänvisningar och motsvarande commit-SHA:er, inklusive transitiva beroenden – alltså actions som andra actions använder. Filen skapas med GitHub CLI-tillägget gh actions-lock; den ska inte redigeras manuellt.

Generatorn kan också precisera uses-hänvisningar i arbetsflödesfilerna: till exempel göra en hänvisning till en flytande tagg mer specifik genom att bevara den commit som taggen löstes upp till när låsfilen skapades. Därför bör hela diffen granskas vid införandet – både ändringar i arbetsflödet och i låsfilen – och teamet bör kontrollera att den låsta versionen är den som det avser att köra.

Därefter blir en beroendeuppdatering en synlig ändring i kodförrådet: teamet kan granska commit-ändringen, diskutera den och godkänna den genom den vanliga granskningen. Låsfilen hjälper till att granska action-koden och hålla beroendena konsekventa; i sig bekräftar den inte att den valda koden är säker.

Var går gränsen för vad som låses?

Anrop av återanvändbara arbetsflöden i jobs.<job_id>.uses låses inte av kodförrådets låsfil. Beroendena för ett återanvändbart arbetsflöde hör till kodförrådet där arbetsflödet definieras. Lås själva anropet genom att ange en fullständig commit-SHA; för att låsa dess actions behöver källkodsförrådet en egen låsfil.

Låsfilen kontrollerar action-koden, men inte andra byggindata, som parametrar som skickas till en action, hemligheter eller runner-avbildningen. Den besvarar en konkret fråga: vilken commit av action-koden kommer att köras? Dessa andra delar kräver egna styrningsregler.

Det finns också ett specialfall: en lokal action som anropas via en sökväg som uses: ./. Enligt GitHubs instruktioner låser eller analyserar tillägget gh actions-lock inte en lokal sökväg till en action. Om en sådan action använder andra actions måste beroendena hanteras separat; dokumentationen beskriver ett sätt att migrera hänvisningar till lokala actions till formatet $/.

En post i låsfilen kan alltså ingå i en beroendekedja, men ersätter inte kontrollen av alla dess länkar. För ett externt återanvändbart arbetsflöde bör du kontrollera att anropet är låst och granska källkodsförrådet. För lokala actions bör du kontrollera hur deras beroenden hanteras.

Hur inför man kontroller utan att CI plötsligt stannar?

GitHub rekommenderar att först genomföra ett pilotprojekt med utvalda kodförråd och arbetsflöden. Policyn Require lockfile blockerar körningar av berörda arbetsflöden utan en giltig låsfil, även arbetsflöden utan beroenden av typen uses:. Läget Evaluate för policyer är bara tillgängligt i GitHub Enterprise Cloud. Börja därför med att fastställa omfattningen och automatisera uppdateringar innan du aktiverar det obligatoriska kravet.

1. Kontrollera de ursprungliga hänvisningarna. Innan du skapar låsfilen ska du försäkra dig om att actions hänvisar till versioner som teamet verkligen vill låsa. Generatorn låser den commit som den aktuella hänvisningen löses upp till.
2. Skapa och granska låsfilen. Installera tillägget gh-actions-lock, kör gh actions-lock från kodförrådets rot och granska hela diffen, även omskrivna uses-hänvisningar.
3. Ställ in uppdateringar och verifiering. Dependabot kan uppdatera motsvarande poster för arbetsflöden som redan har kopplats in. I CI kan du konfigurera en verifieringsuppgift för pull requests med gh actions-lock --verify, så att en inaktuell låsfil upptäcks innan huvudbygget.
4. Utse granskare. Lägg till .github/workflows/actions.lock i CODEOWNERS och kräv att personer med ansvar för byggsäkerheten granskar ändringar.
5. Genomför ett pilotprojekt för policyn. Börja med anslutna kodförråd och arbetsflöden. Analysera resultaten i Evaluate-läget; kontrollera att alla berörda arbetsflöden är förberedda och att låsfilerna är aktuella innan du går över till Active-läget.

Require lockfile och den separata policyn Require actions to be pinned to a full-length commit SHA är olika regler; GitHub anger att de kan användas samtidigt. CI-kontrollen och den obligatoriska policyn fyller också olika funktioner: den första upptäcker en inaktuell fil under arbetet med en pull request, medan den andra blockerar körningar av arbetsflöden som inte uppfyller kravet.

Exempel: uppdatering av en deployment-action

Anta att ett arbetsflöde publicerar ett program med octo-org/deploy-action@v3. Först kontrollerar teamet vilken version hänvisningen löser upp till, kör sedan gh actions-lock och granskar diffen av arbetsflödet tillsammans med commit-posten i låsfilen. När actionen uppdateras ser granskaren ändringarna i hänvisningarna och den låsta commit-versionen. Det gör det möjligt att bedöma den specifika uppdateringen i stället för att lita på att en flytande tagg alltid pekar på samma kod.

Om deploymenten utförs av ett återanvändbart arbetsflöde i ett annat kodförråd omfattar den lokala låsfilen inte dess beroenden. Lås hänvisningen till det återanvändbara arbetsflödet med en fullständig SHA och kontrollera att källkodsförrådet hanterar sina egna action-beroenden. I stora organisationer gör detta utspridda regler till en kontrollerbar process, samtidigt som parametrar, hemligheter och runner hanteras separat.

En låsfil är ett användbart lager för kontroll av action-kod: den gör versioner och uppdateringar synliga, inklusive transitiva beroenden. För att få tillförlitlig täckning bör du även kontrollera återanvändbara arbetsflöden och lokala actions, automatisera uppdateringar och införa en obligatorisk policy först efter ett pilotprojekt.