Lockfile for GitHub Actions låser kjørbar kode, men ikke hele CI

Kan du stole på GitHub Actions når en arbeidsflyt viser til en action med en tag som @v3? Lockfile-filen angir hvilken commit av actionen som skal kjøres, selv om taggen senere flyttes. Teamet kan gjennomgå avhengighetsoppdateringer i diffen og føre en kontrollerbar oversikt over actions som brukes i CI. Den praktiske avgrensningen er at lockfile-filen dekker actions som kalles fra trinn, mens en gjenbrukbar arbeidsflyt som kalles på jobbnivå, må låses separat. Mekanismen som beskrives, er tilgjengelig i GitHub Enterprise Cloud.

Hva er det egentlig lockfile-filen låser?

Lenker til grener og tagger er praktiske, men versjonen de peker på, kan endres. En oppføring som uses: octo-org/deploy-action@v3 viser til et tagnavn; GitHub løser lenken til en commit når arbeidsflyten kjøres. Hvis prosjekteieren flytter taggen, kan en senere kjøring få annen kode dersom avhengigheten ikke er låst.

Ifølge GitHubs dokumentasjon om lockfile lagrer filen .github/workflows/actions.lock avhengighetslenker og tilhørende commit-SHA-er, også for transitive avhengigheter – actions som brukes av andre actions. Filen opprettes av GitHub CLI-utvidelsen gh actions-lock; den skal ikke redigeres manuelt.

Generatoren kan også gjøre uses-lenker i arbeidsflytfilene mer presise: Den kan for eksempel gjøre en lenke til en flytende tag mer konkret og samtidig beholde commiten som lenken ble løst til da lockfile-filen ble opprettet. Ved innføring bør derfor hele diffen – endringene i arbeidsflyten og lockfile-filen – gjennomgås. Kontroller at den låste versjonen er den teamet faktisk ønsker å kjøre.

Deretter blir oppdateringer av avhengigheter synlige endringer i repositoriet: Teamet kan kontrollere endringen av commit, diskutere den og godkjenne den gjennom den vanlige kodegjennomgangen. Lockfile-filen gjør det enklere å revidere action-kode og holde avhengighetene konsistente, men bekrefter ikke i seg selv at den valgte koden er sikker.

Hvor slutter låsingen?

Kall av en gjenbrukbar arbeidsflyt i jobs.<job_id>.uses låses ikke av lockfile-filen i repositoriet som kaller den. Avhengighetene til den gjenbrukbare arbeidsflyten hører til repositoriet der arbeidsflyten er definert. For å låse selve kallet angir du hele commit-SHA-en. Hvis også actionene i arbeidsflyten skal låses, må kilde­repo­sitoriet ha sin egen lockfile-fil.

Lockfile-filen kontrollerer action-kode, men ikke andre bygginndata, som parametere som sendes til en action, hemmeligheter eller runner-avbildningen. Den besvarer et avgrenset spørsmål: Hvilken commit av action-koden blir kjørt? De øvrige elementene krever egne kontrollregler.

Et særtilfelle er en lokal action som kalles via en sti som uses: ./. Ifølge GitHubs veiledning låser eller analyserer utvidelsen gh actions-lock ikke en lokal action-sti. Hvis en slik action bruker andre actions, må avhengighetene håndteres separat. Dokumentasjonen beskriver en måte å migrere referanser til lokale actions til formatet $ / på.

En oppføring i lockfile-filen kan altså være ett ledd i kjeden, men erstatter ikke kontrollen av alle leddene. For en ekstern gjenbrukbar arbeidsflyt bør du kontrollere at kallet er låst, og undersøke tilstanden til kilde­repo­sitoriet. For lokale actions bør du sjekke hvordan avhengighetene deres blir håndtert.

Slik innfører du kontroll uten at CI stopper uventet

GitHub anbefaler først å prøve ordningen på utvalgte repositorier og arbeidsflyter. Policyen Require lockfile blokkerer kjøring av målrettede arbeidsflyter uten en gyldig lockfile-fil, også arbeidsflyter uten uses:-avhengigheter. Modusen Evaluate for policyer er bare tilgjengelig i GitHub Enterprise Cloud. Forbered derfor omfanget og automatiske oppdateringer før du gjør regelen obligatorisk.

1. Kontroller de opprinnelige lenkene. Før du oppretter lockfile-filen, må du forsikre deg om at actions viser til versjoner teamet faktisk vil låse. Generatoren låser commiten som løses ut fra den gjeldende lenken.
2. Opprett og gjennomgå lockfile-filen. Installer utvidelsen gh-actions-lock, kjør gh actions-lock fra roten av repositoriet, og gjennomgå hele diffen, inkludert omskrevne uses-lenker.
3. Sett opp oppdateringer og kontroll. Dependabot kan oppdatere de aktuelle oppføringene for arbeidsflyter som allerede er konfigurert. I CI kan du sette opp en kontrolljobb for pull requests med gh actions-lock --verify, slik at utdaterte lockfile-filer oppdages før hovedbygget.
4. Utpek kontrollører. Legg til .github/workflows/actions.lock i CODEOWNERS, og krev at personer med ansvar for byggsikkerhet gjennomgår endringer.
5. Prøvekjør policyen. Begynn med de tilkoblede repositoriene og arbeidsflytene. Analyser resultatene i Evaluate-modus. Før du bytter til Active, må du kontrollere at alle målrettede arbeidsflyter er klargjort, og at lockfile-filene er oppdaterte.

Require lockfile og den separate policyen Require actions to be pinned to a full-length commit SHA er ulike regler; GitHub oppgir at begge kan brukes samtidig. CI-kontroll og obligatorisk policy har også ulike roller: Den første oppdager en utdatert fil mens man arbeider med en pull request, mens den andre blokkerer kjøring av arbeidsflyter som ikke oppfyller kravet.

Eksempel: oppdatering av en deployment-action

Anta at en arbeidsflyt publiserer en app via octo-org/deploy-action@v3. Først kontrollerer teamet hvilken versjon lenken løses til. Deretter kjører de gh actions-lock og gjennomgår diffen for arbeidsflyten sammen med commit-oppføringen i lockfile-filen. Ved oppdatering av actionen kan den som kontrollerer endringen, se hva som er endret i lenkene og den låste commiten. Dermed kan oppdateringen vurderes konkret, uten å stole på at en flyttbar tag alltid peker på den samme koden.

Hvis utrullingen utføres av en gjenbrukbar arbeidsflyt i et annet repositorium, omfatter ikke den lokale lockfile-filen arbeidsflytens avhengigheter. Lås lenken til den gjenbrukbare arbeidsflyten med en full SHA, og kontroller at kilde­repo­sitoriet håndterer sine egne action-avhengigheter. I store organisasjoner gjør dette spredte regler til en kontrollerbar prosess, samtidig som parametere, hemmeligheter og runner fortsatt håndteres separat.

Lockfile-filen er et nyttig kontrollag for action-kode: Den gjør versjoner og oppdateringer oversiktlige, også for transitive avhengigheter. For å sikre bred dekning bør du også kontrollere gjenbrukbare arbeidsflyter og lokale actions, automatisere oppdateringer og først gjøre policyen obligatorisk etter en prøveperiode.