GitHub Actionsin lockfile kiinnittää suoritettavan koodin, muttei koko CI:tä

Voiko GitHub Actionsiin luottaa, jos workflow viittaa actioniin tunnisteella, kuten @v3? Lockfile määrittää, mikä actionin commit suoritetaan, vaikka tunniste myöhemmin siirtyisi. Tiimi voi tarkastella riippuvuuspäivityksiä diffissä ja ylläpitää tarkistettavaa luetteloa CI:ssä käytettävistä actions-toiminnoista. Käytännön rajaus: lockfile kattaa vaiheissa kutsutut actions-toiminnot, mutta job-tasolla kutsuttava uudelleenkäytettävä workflow on kiinnitettävä erikseen. Kuvattu mekanismi on saatavilla GitHub Enterprise Cloudissa.

Mitä lockfile tarkalleen ottaen kiinnittää?

Viittaukset haaroihin ja tunnisteisiin ovat käteviä, mutta niiden osoittama versio voi muuttua. Esimerkiksi uses: octo-org/deploy-action@v3 viittaa tunnisteeseen; GitHub ratkaisee sen commitiksi suorituksen yhteydessä. Jos projektin omistaja siirtää tunnistetta, seuraava suoritus voi saada eri koodia, ellei riippuvuutta ole kiinnitetty.

GitHubin lockfile-dokumentaation mukaan tiedosto .github/workflows/actions.lock tallentaa riippuvuusviittaukset ja niitä vastaavat commit SHA:t, myös transitiiviset riippuvuudet eli muiden actions-toimintojen käyttämät actions-toiminnot. Tiedoston luo GitHub CLI:n laajennus gh actions-lock; sitä ei muokata käsin.

Generaattori voi myös tarkentaa workflow-tiedostojen uses-viittauksia: esimerkiksi muuttaa liikkuvaan tunnisteeseen viittaavan osoitteen täsmällisemmäksi ja säilyttää sen commitin, johon viittaus lockfilea luotaessa ratkesi. Käyttöönoton yhteydessä on siksi tarkasteltava koko diff — workflow-muutokset ja lockfile — ja varmistettava, että kiinnitetty versio on se, jonka tiimi haluaa suorittaa.

Tämän jälkeen riippuvuuden päivitys näkyy repositoriossa muutoksena: tiimi voi tarkastaa commit-muutoksen, keskustella siitä ja hyväksyä sen tavallisen review-prosessin kautta. Lockfile auttaa auditoimaan actions-koodia ja ylläpitämään riippuvuuksien yhdenmukaisuutta; se ei yksin vahvista valitun koodin turvallisuutta.

Missä kiinnittämisen soveltamisala päättyy?

jobs.<job_id>.uses-määrityksellä kutsuttua uudelleenkäytettävää workflow’ta ei kiinnitetä sitä kutsuvan repositorion lockfileen. Uudelleenkäytettävän workflow’n riippuvuudet kuuluvat repositorioon, jossa workflow on määritelty. Kiinnitä itse kutsu täydellä commit SHA:lla; sen sisältämien actions-toimintojen kiinnittäminen edellyttää omaa lockfilea lähderepositoriossa.

Lockfile hallitsee actions-koodia, mutta ei muita buildin syötteitä, kuten actionille välitettyjä parametreja, salaisuuksia tai runner-ympäristöä. Se vastaa rajattuun kysymykseen: minkä action-koodin commit suoritetaan? Näitä muita osia varten tarvitaan omat hallintasäännöt.

Erityistapaus on myös paikallinen action, johon viitataan polulla, kuten uses: ./. GitHubin ohjeiden mukaan gh actions-lock-laajennus ei kiinnitä eikä analysoi paikallista action-polkua. Jos tällainen action käyttää muita actions-toimintoja, riippuvuudet on hallittava erikseen; dokumentaatiossa kuvataan vaihtoehto, jossa paikallisten actions-toimintojen viittaukset siirretään $/-muotoon.

Yksi lockfile-merkintä voi siis olla osa ketjua, mutta se ei korvaa ketjun kaikkien lenkkien hallintaa. Tarkista ulkoisen, uudelleenkäytettävän workflow’n osalta kutsun kiinnitys ja lähderepositorion tila; paikallisten actions-toimintojen kohdalla selvitä, miten niiden riippuvuudet huomioidaan.

Miten hallinta otetaan käyttöön pysäyttämättä CI:tä yllättäen?

GitHub suosittelee ensin pilottia valituissa repositorioissa ja workflow’ssa. Require lockfile -käytäntö estää kohteeksi määritettyjen workflow’iden suorituksen, jos niistä puuttuu kelvollinen lockfile — myös silloin, kun workflow ei sisällä yhtään uses:-riippuvuutta. Evaluate-tila käytännöille on saatavilla vain GitHub Enterprise Cloudissa. Määritä siis ensin soveltamisala ja automaattiset päivitykset ja ota pakollinen sääntö käyttöön vasta sen jälkeen.

1. Tarkista alkuperäiset viittaukset. Varmista ennen lockfilen luomista, että actions-toiminnot viittaavat versioihin, jotka tiimi todella haluaa kiinnittää. Generaattori lukitsee nykyisestä viittauksesta ratkaistun commitin.
2. Luo lockfile ja tarkasta se. Asenna gh-actions-lock-laajennus, suorita gh actions-lock repositorion juuresta ja tarkastele koko diffiä, mukaan lukien uudelleenkirjoitetut uses-viittaukset.
3. Määritä päivitykset ja tarkistukset. Dependabot voi päivittää vastaavat merkinnät jo käyttöön otetuissa workflow’issa. CI:n pull request -tarkistukseen voi määrittää tarkistustehtävän komennolla gh actions-lock --verify, jotta vanhentunut lockfile havaitaan ennen varsinaista buildia.
4. Nimeä tarkastajat. Lisää .github/workflows/actions.lock CODEOWNERS-tiedostoon ja edellytä buildin turvallisuudesta vastaavien hyväksyntää muutoksille.
5. Pilotoi käytäntöä. Aloita käyttöön otetuista repositorioista ja workflow’ista. Analysoi tulokset Evaluate-tilassa; ennen Active-tilaa varmista, että kaikki kohteeksi määritetyt workflow’t on valmisteltu ja lockfilet ovat ajan tasalla.

Require lockfile ja erillinen Require actions to be pinned to a full-length commit SHA -käytäntö ovat eri sääntöjä; GitHubin mukaan niitä voi käyttää samanaikaisesti. CI-tarkistus ja pakollinen käytäntö palvelevat myös eri tarkoituksia: ensimmäinen havaitsee vanhentuneen tiedoston pull requestin käsittelyn aikana, toinen estää vaatimuksen vastaisen workflow’n suorittamisen.

Esimerkki: deployment-actionin päivittäminen

Oletetaan, että workflow julkaisee sovelluksen komennolla octo-org/deploy-action@v3. Ensin tiimi tarkistaa, minkä version viittaus ratkaisee, suorittaa sitten komennon gh actions-lock ja tarkastelee workflow-muutoksia yhdessä lockfilen commit-merkinnän kanssa. Actionin päivityksen yhteydessä tarkastaja näkee viittausten ja kiinnitetyn commitin muutokset, joten hän voi arvioida täsmällisen päivityksen eikä luottaa siihen, että liikkuva tunniste osoittaa aina samaan koodiin.

Jos deployment tehdään toisesta repositoriosta peräisin olevan uudelleenkäytettävän workflow’n avulla, paikallinen lockfile ei kata sen riippuvuuksia. Kiinnitä viittaus uudelleenkäytettävään workflow’hun täydellä SHA:lla ja tarkista, että lähderepositorio hallitsee omat actions-riippuvuutensa. Suurissa organisaatioissa tämä muuttaa hajanaiset säännöt tarkistettavaksi prosessiksi, mutta parametrien, salaisuuksien ja runner-ympäristön hallinta säilyy erillisenä.

Lockfile on hyödyllinen actions-koodin hallintakerros: se tekee versiot ja päivitykset näkyviksi, myös transitiiviset riippuvuudet. Kattavan hallinnan varmistamiseksi tarkista myös uudelleenkäytettävät workflow’t ja paikalliset actions-toiminnot, automatisoi päivitykset ja ota pakollinen käytäntö käyttöön vasta pilotin jälkeen.