Passaggio a Ubuntu 26.04 su GitHub Actions: verificare le differenze dei runner partendo dallo stesso commit
Anche senza modificare il codice sorgente, l'esito della CI può cambiare. Se i tuoi flussi di lavoro si affidano a ubuntu-latest per l'ambiente di esecuzione, il passaggio dell'immagine del sistema operativo è una modifica che il team deve gestire attivamente.
GitHub ha annunciato il supporto ufficiale per i runner Ubuntu 26.04 e il piano di migrazione di ubuntu-latest per il 17 settembre 2026. Questo articolo non intende sostenere che la nuova immagine sia semplicemente più veloce, ma propone una guida pratica per isolare e verificare le differenze d'ambiente utilizzando lo stesso commit.
L'ambito confermato dall'annuncio ufficiale
In base all'annuncio, le immagini Ubuntu 26.04 saranno supportate ufficialmente su x64 e arm64 con le etichette esplicite ubuntu-26.04 e ubuntu-26.04-arm. ubuntu-latest passerà progressivamente da Ubuntu 24.04 a 26.04 tra il 19 ottobre e il 19 novembre 2026.
La nuova immagine include strumenti aggiornati o rimossi, il che potrebbe influire sulle build che dipendono da pacchetti preinstallati. Se la preparazione non è ancora completa, GitHub suggerisce di specificare esplicitamente ubuntu-24.04. Questo calendario non indica necessariamente la data effettiva del passaggio per ciascun singolo repository.
Definire l'ambiente atteso dal nostro repository
Per prima cosa, controlla runs-on nei tuoi flussi di lavoro principali e in quelli riutilizzabili. Non dare per scontato che l'impatto dell'host scompaia solo perché si usano i container; è consigliabile esaminare anche i passaggi di installazione, compressione e caricamento eseguiti all'esterno del container.
Prova a redigere una lista di controllo suddividendo compilatori, runtime, gestori di pacchetti e librerie di sistema. Invece di limitarti a elencare i nomi degli strumenti, collega il luogo da cui vengono installati con i passaggi che li invocano: in questo modo sarà più facile risalire alla causa nei log di errore.
Stesso commit, due ambienti, artefatti indipendenti
È più chiaro iniziare i test di transizione su percorsi di verifica privi di autorizzazioni di distribuzione. Esegui lo stesso commit e lo stesso file di lock sull'immagine esistente e su quella nuova, conservando separatamente log, risultati dei test e nomi degli artefatti. Questo è il metodo di convalida proposto in questo articolo.
Nel confronto iniziale, annota le condizioni della cache per poter distinguere l'impatto dei dati obsoleti. Oltre a verificare il successo della build, devi registrare le versioni degli strumenti installati, i passaggi falliti e gli esiti dell'esecuzione degli artefatti per individuare i casi in cui il passaggio è riuscito solo per puro caso grazie a un cache hit.
La verifica che resta dietro la spunta verde
In un progetto web puoi controllare se i file generati possono essere effettivamente distribuiti; in presenza di dipendenze native, verifica che vengano caricate nell'ambiente di destinazione. Invece di imporre la regola che ogni singolo byte degli artefatti debba essere identico, valuta separatamente le discrepanze funzionali da quelle non deterministiche, come i timestamp.
Chi effettua la revisione deve poter consultare in un unico punto il link di esecuzione sulla nuova immagine, le differenze di versione degli strumenti, i risultati dei controlli delle funzionalità rappresentative e le modifiche necessarie per un eventuale ripristino. Mescolare il refactoring dell'applicazione con il cambio di runner amplierebbe inutilmente le possibili cause di fallimento e il raggio d'azione del rollback.
Vantaggi e limiti del blocco dell'immagine
Un'etichetta esplicita del sistema operativo aiuta a mantenere il controllo durante le transizioni importanti, ma non garantisce un ambiente di compilazione del tutto immutabile. Mantieni l'abitudine di installare in modo esplicito gli strumenti necessari per l'esecuzione e di registrare le versioni effettive nei log.
Nei repository più piccoli non è necessario allestire una procedura di convalida mastodontica. Si può iniziare confrontando una build rappresentativa e le dipendenze più critiche; se si applica un blocco temporaneo della versione, basta annotare la data in cui riesaminarlo insieme al responsabile incaricato della rimozione del vincolo.
Separare le discussioni pubbliche dalle decisioni del team
I ticket pubblici su runner-images sono il canale ideale per verificare le modifiche alle immagini e le segnalazioni di problemi. Tuttavia, un commento specifico o il fallimento di un altro progetto non implicano che lo stesso problema si replichi nel nostro repository, e questo articolo non avanza tesi statistiche sul consenso della community o sulla frequenza dei guasti.
Ciò che va fatto oggi è individuare dove viene impiegata l'etichetta latest e testare lo stesso commit sulla nuova immagine. Mettendo prima per iscritto i criteri di successo e le condizioni di sospensione, i responsabili potranno valutare con le stesse evidenze oggettive anche se le build dovessero cambiare durante il periodo effettivo di transizione.