I lockfile di Actions sono GA: cosa dimostra un controllo verde
Una PR può mostrare la stessa versione uses mentre cambia il codice sottostante. I tag possono spostarsi su altri commit. GitHub ha annunciato la disponibilità generale dei lockfile il 28 ottobre. Dopo l’anteprima, conta capire quali prove fornisca ogni verifica.
Riferimenti leggibili e commit registrati
.github/workflows/actions.lock collega i riferimenti delle action ai commit da eseguire. Si genera con gh actions-lock ed è disponibile per Free, Team e GitHub Enterprise Cloud, compresa la residenza dei dati. Si possono includere singoli workflow. Il file generato va esaminato insieme alle modifiche del workflow, senza comporlo a mano.
In un esempio ipotetico, demo/build@v1 punta prima ad A e poi a B. Risolvere solo il riferimento può selezionare codice diverso alla prossima esecuzione; il lockfile mantiene il commit registrato. La figura non è una prova reale. Un commit non più raggiungibile dal tag o branch registrato può essere rifiutato durante l’esecuzione.
Che cosa verifica il controllo offline?
gh actions-lock --verify-local controlla senza rete la copertura delle voci uses. È utile prima del commit, ma non verifica la provenienza. gh actions-lock --verify la controlla online; il runner ripete il controllo all’avvio del job. Due risultati verdi hanno quindi significati diversi.
Se una PR parallela aggiunge una action senza aggiornare il lockfile, la copertura locale può rilevare la voce mancante. La completezza non prova né provenienza né sicurezza del codice. La seconda figura riassume la documentazione; per questo articolo non abbiamo installato o eseguito la CLI.
I workflow riutilizzabili hanno un altro confine
Le dipendenze transitive delle action sono incluse, ma non le chiamate tramite jobs.<job_id>.uses. Queste vanno fissate con il SHA completo del commit. Le loro action interne seguono il lockfile del repository in cui il workflow è definito, non quello del chiamante.
Immaginiamo un’applicazione che richiami il deployment di un repository piattaforma. Il solo actions.lock dell’applicazione non rivela i commit delle action della piattaforma. Occorre collegare SHA di chiamata e dipendenze della piattaforma. Immagine del runner, input e segreti restano separati: fissare una action non congela tutto l’ambiente.
Leggere insieme i due file negli aggiornamenti
Quando Dependabot aggiorna una action di un workflow incluso, rigenera la relativa voce del lockfile nella stessa PR. Si possono così confrontare versione leggibile e commit effettivo. --relock avanza i riferimenti spostati e scrive file: non è una verifica in sola lettura. La revisione del codice resta necessaria.
Require lockfile può imporre l’adozione senza eliminare i confini tra repository. Partire da un workflow aiuta a capire generazione, revisione e verifica online. Al prossimo controllo verde, chiedetevi quale prova offra: copertura, provenienza o revisione del codice selezionato.