GitHub Actions

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 1 di 14. La maggior parte delle build enterprise viene gestita come un ripensamento in un tool completamente separato. Fai il push del codice, avviene un context switch e speri che un webhook scatti correttamente su un server remoto da qualche altra parte. Il caso d'uso enterprise di GitHub Actions risolve questo gap spostando l'esecuzione della tua pipeline direttamente accanto al tuo codice sorgente. L'errore comune è considerare GitHub Actions strettamente come un tool di CI/CD, come se fosse solo un moderno sostituto di Jenkins. Chiamalo per quello che è realmente. È un motore di automazione flessibile, event-driven, profondamente integrato nel tuo repository. Risponde praticamente a qualsiasi cambio di stato all'interno della piattaforma di version control. Prendi un setup enterprise standard che usa tool come GCP Cloud Build o Azure DevOps. Il codice sorgente risiede su GitHub, ma l'esecuzione avviene altrove. Questo richiede la gestione di service account cross-platform, la manutenzione di webhook fragili e la sincronizzazione dei controlli di accesso tra vendor multipli. Quando una pipeline fallisce, i developer lasciano il loro repository, fanno login in una cloud console separata e spulciano log disconnessi dalla loro pull request. La vicinanza al codice rimuove questo attrito. Quando il tuo motore di automazione è integrato direttamente nella piattaforma di version control, elimini il costo di integrazione. L'identità dell'utente, le branch protection rules e il contesto della modifica al codice vengono compresi nativamente dall'istanza compute che esegue la tua pipeline. Considera una pipeline tradizionale in un tool di cloud build separato. Tipicamente resta in ascolto di un commit del codice, fa il pull dei sorgenti, compila un artifact e riporta un semplice stato di pass o fail al repository. La sua intera visione del mondo è limitata alla compilazione del codice e al deploy. Una GitHub Action opera su una scala molto più ampia. Dato che comprende nativamente gli eventi del repository, puoi creare un workflow che scatta nel momento esatto in cui si apre una pull request. In un'unica run fluida, può leggere il payload dell'evento, assegnare i giusti senior engineer come reviewer in base a quali file specifici sono cambiati, eseguire un linter e postare eventuali errori di sintassi direttamente come commenti inline sulle esatte righe di codice. Il developer risolve le issue senza mai uscire dalla vista della pull request. Automatizzi il workflow stesso, non solo l'artifact della build. Da un punto di vista architetturale, questo trasforma il tuo repository da un volume di storage passivo a un controller attivo. Smetti di automatizzare solo i tuoi deploy e inizi ad automatizzare la tua governance operativa. Se una issue viene taggata con una label critica, un'action può fare automaticamente il provisioning di un database di testing temporaneo. Se una vulnerabilità di sicurezza viene segnalata da una dependency scan automatizzata, un'action può aprire all'istante un ticket di tracciamento, assegnare il security team e pingare il tuo sistema di chat interno. Tutto utilizza la stessa identica infrastruttura compute sottostante. In una grande organizzazione, puoi definire questi workflow centralmente e condividerli su centinaia di repository. Se il tuo security team aggiorna la policy di container scanning richiesta, aggiorna una singola action centrale. Ogni repository che chiama quell'action eredita immediatamente il nuovo requisito di sicurezza, senza che i singoli product team debbano riscrivere i loro script della pipeline. Questa centralizzazione offre un enorme vantaggio ai team di platform engineering. Ecco l'intuizione chiave. L'architettura enterprise si scontra costantemente con il tool sprawl. Ogni nuovo tool di pipeline aggiunge carico cognitivo, richiede manutenzione dedicata e crea un'altra superficie per le security policy. Consolidando il tuo execution layer direttamente in GitHub, standardizzi il comportamento di ogni repository. La stessa identica infrastruttura che fa il deploy dei tuoi microservizi in produzione gestisce anche la manutenzione del tuo repository. Il vantaggio architetturale definitivo di GitHub Actions non è avere build agent più veloci o un caching migliore. È che rimuove il confine tra il workflow del developer e il sistema di continuous integration. Se trovi utili questi episodi e vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon. Grazie per l'ascolto, e buon coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 2 di 14. Un workflow non è un semplice script che viene eseguito dall'alto verso il basso. È una macchina a stati parallelizzata che distribuisce il tuo codice su più macchine virtuali esattamente nello stesso momento. Se scrivi la tua configurazione aspettandoti un unico processo continuo, i tuoi dati spariranno a metà strada. Capire il modello mentale di esecuzione evita che questo accada. Al livello più alto c'è il workflow. Si tratta di un processo automatizzato e configurabile, definito in un file YAML all'interno del tuo repository. Contiene il blueprint di quello che deve succedere quando viene triggerato. Un workflow di per sé non esegue il codice direttamente. Orchestra il livello inferiore. Un workflow contiene uno o più job. È qui che vengono stabiliti i confini fisici dell'esecuzione. Di default, ogni job in un workflow gira in parallelo. Se definisci un job di build e un job di test, GitHub avvia una macchina virtuale separata, chiamata runner, per ogni job. Partono esattamente nello stesso momento. Non sanno nulla l'uno dell'altro. Il job di build gira sul runner A, e il job di test gira sul runner B. Dato che girano su macchine virtuali completamente diverse, non condividono il filesystem, le variabili d'ambiente o la memoria. All'interno di un job, il modello di esecuzione cambia completamente. Un job è composto da una sequenza di step. Mentre i job girano in parallelo su macchine diverse, gli step girano in modo sequenziale sulla stessa identica macchina. Lo step uno finisce prima che inizi lo step due. Dato che girano sullo stesso runner, gli step condividono i dati. Nel nostro job di build, lo step uno potrebbe scaricare il codice della tua applicazione. Lo step due lo compila. Lo step tre lo impacchetta. Dato che questi step avvengono sulla stessa macchina virtuale, lo step due legge nativamente i file scaricati dallo step uno. Questo ci porta a un punto di confusione molto comune. Spesso le persone confondono gli step e le action. Uno step non è un'action. Uno step è semplicemente un'unità di esecuzione all'interno di un job. È uno slot nella tua sequenza. Puoi riempire quello slot in due modi. Puoi scrivere un comando shell puro, oppure puoi richiamare un'action. Un'action è un blocco di codice pacchettizzato e riutilizzabile, progettato per eseguire un task complesso e specifico, come il setup di un ambiente per un linguaggio. L'action è il payload riutilizzabile. Lo step è il contenitore che la ospita all'interno della sequenza del job. Diamo di nuovo un'occhiata al nostro scenario di build e test. Il workflow parte. Due runner si avviano in simultanea. Sul runner di build, gli step vengono eseguiti uno a uno. Il primo step chiama un'action di checkout per recuperare il repository. Il secondo step lancia un comando shell per compilare il codice. Questi step condividono lo spazio sul disco locale senza problemi. Nel frattempo, sul runner di test, una sequenza di step completamente diversa sta girando in isolamento. Se il tuo job di test ha bisogno dell'output compilato dal job di build, non può semplicemente guardare sul disco fisso. Il job di test si trova su un server diverso. Ecco il concetto chiave. Il confine di un job è il confine fisico della macchina virtuale, il che significa che scrivere un workflow di GitHub Actions è a tutti gli effetti un esercizio di mappatura dell'infrastruttura. Grazie per avermi fatto compagnia. Spero tu abbia imparato qualcosa di nuovo.

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 3 di 14. Un singolo commit automatico viene pushato sul tuo repository. Quel commit triggera un workflow. Quel workflow fa un altro commit, che triggera di nuovo il workflow. Nel giro di pochi minuti, hai bruciato centinaia di run minutes in un loop infinito accidentale. Il modo in cui previeni questo problema, e controlli esattamente quando i tuoi workflow vengono eseguiti, è tramite trigger e filtri event-driven. Ogni workflow di GitHub Actions inizia con la keyword on. Questo dice a GitHub quali eventi devono svegliare il tuo workflow. Puoi specificare un singolo evento, come un push, o più eventi in un array. Ma gli eventi non sono sempre semplici trigger. Alcuni eventi, come le issue o le pull request, hanno diversi activity type. Quando una issue viene aperta, modificata o chiusa, lancia lo stesso evento di base. Se scrivi semplicemente che un workflow gira sulle issue, girerà per tutte quelle attività. Per essere preciso, specifichi gli activity type esatti. Puoi dire a GitHub di eseguire il workflow solo quando una issue viene aperta, ignorando le modifiche o le chiusure. Questo ti fa risparmiare run minutes ed evita elaborazioni inutili. Gli activity type gestiscono cosa è successo, ma i branch filter e i path filter gestiscono dove è successo. Quando triggeri un workflow su un push o una pull request, di solito non vuoi che giri su ogni singolo branch. Usi i branch filter per puntare a destinazioni specifiche, come il branch main o i branch di release. Puoi anche filtrare per path. Se uno sviluppatore corregge un errore di battitura in un file readme, non hai bisogno di eseguire l'intera test suite. I path filter ti permettono di includere o escludere file e directory specifici. Ecco il punto chiave. Quando mischi path filter positivi e negativi, l'ordine in cui li scrivi è importante. Un filtro positivo dice al workflow di partire se un path specifico cambia. Un filtro negativo, indicato da un punto esclamativo, dice al workflow di ignorare le modifiche in un path. GitHub li valuta dall'alto verso il basso. Se metti un filtro negativo dopo un filtro positivo, il filtro negativo sovrascrive quello positivo per tutti i file corrispondenti. Mettiamolo in pratica. Vuoi triggerare una build ogni volta che il codice viene pushato sul branch main, ma vuoi risparmiare ignorando le modifiche che riguardano solo la documentazione. Sotto la keyword on, specifichi l'evento di push. Lì sotto, definisci un branch filter per main. Poi, aggiungi un path filter. Potresti iniziare con un filtro positivo per tutto, usando una wildcard. Subito sotto, aggiungi un filtro negativo per la cartella docs, puntando specificamente ai file markdown. Se un commit modifica solo un file markdown nella cartella docs, il workflow rimane inattivo. Se un commit modifica un file python e un file markdown, il workflow viene eseguito perché il file python triggera il filtro positivo. Ora torniamo a quel loop infinito. Quando il tuo workflow gira, GitHub fornisce una credenziale temporanea chiamata GitHub Token per l'autenticazione con il repository. By design, qualsiasi evento triggerato usando questo token specifico non creerà nuove run del workflow. Questo è un meccanismo di sicurezza integrato per prevenire loop ricorsivi. Tuttavia, se il tuo workflow usa un Personal Access Token per fare il commit del codice o il push di tag, quella rete di sicurezza sparisce. Il nuovo commit triggererà un'altra run del workflow, che farà un altro commit, creando un loop infinito. Se proprio devi usare un Personal Access Token, devi essere estremamente disciplinato con i tuoi branch filter e path filter per assicurarti che il commit automatico non soddisfi le condizioni di trigger per il workflow. Il modo più efficace per ottimizzare i tuoi costi di calcolo non è scrivere codice più veloce, ma semplicemente assicurarti che i tuoi workflow girino solo quando è assolutamente necessario. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 4 di 14. Provi a usare una variabile d'ambiente del runner per decidere se un job deve partire, e la tua pipeline fallisce prima ancora di avviare una macchina. Sei certo che la variabile esista, ma GitHub si comporta come se fosse vuota. Il problema non è la tua variabile, è il tempismo. Per risolvere questo problema, dobbiamo parlare di State Evaluation con variabili e Context. In GitHub Actions, lo stato del tuo workflow viene valutato in due fasi completamente separate, che avvengono in due posti completamente diversi. Questa è la differenza fondamentale tra un Context e una variabile d'ambiente. Guardiamo prima i Context. I Context sono insiemi di informazioni valutate direttamente da GitHub, prima ancora che il tuo workflow venga inviato a un runner. Contengono dati sulla run del workflow, sul repository, sull'evento webhook che ha triggerato la run e sull'utente che l'ha avviata. Dato che GitHub valuta i Context immediatamente, puoi usarli per controllare la struttura della tua pipeline. Accedi a un Context usando una sintassi specifica per le espressioni, di solito un simbolo del dollaro seguito da doppie parentesi graffe che contengono il nome del Context. D'altra parte, le variabili d'ambiente di default vengono valutate in un secondo momento, direttamente sulla macchina runner che esegue il tuo job. Quando il runner si avvia, imposta automaticamente diverse variabili d'ambiente di default, come il nome del repository o il branch corrente. Puoi accedervi esattamente come faresti in un normale script bash o PowerShell. Puoi anche definire le tue variabili d'ambiente usando la chiave env nel file del tuo workflow. Puoi attaccare la chiave env a un intero workflow, a un singolo job o a uno step specifico. Ecco il punto chiave. Il ciclo di vita determina cosa puoi usare e dove. Un errore comune è cercare di usare una variabile d'ambiente del runner all'interno di un condizionale if a livello di job. Se dici a un job di partire solo se una specifica variabile d'ambiente bash è uguale a un certo valore, il workflow fallirà. Il runner non è ancora partito. La macchina non esiste, quindi la variabile d'ambiente non esiste. Per prendere decisioni prima che il runner si avvii, devi usare un Context. Vediamo uno scenario pratico. Vuoi che un job di deploy parta solo se il codice viene mergiato nel branch main. A livello di job, scrivi un condizionale if. Usi l'espressione del Context per verificare se il Context github dot ref è uguale alla string refs slash heads slash main. GitHub lo valuta all'istante. Se è vero, GitHub prepara un runner e gli invia il job. Una volta che il job è sul runner e i tuoi step iniziano l'esecuzione, passi alle variabili d'ambiente. All'interno di uno step con uno script bash in quello stesso job, potresti aver bisogno di conoscere il nome del branch per taggare un artifact di build. Qui, digiti semplicemente un simbolo del dollaro seguito da GITHUB underscore REF. Il runner legge questo dato dall'ambiente del suo sistema operativo locale. Stai facendo riferimento allo stesso identico dato, il nome del branch, ma ci stai accedendo tramite meccanismi completamente diversi a seconda di dove si trova l'esecuzione in quel momento. I Context instradano il workflow sui server di GitHub. Le variabili d'ambiente guidano l'esecuzione degli script sul runner. Se ti ritrovi mai a combattere con variabili vuote nella logica del tuo workflow, chiediti se la macchina che valuta quella logica si è effettivamente già avviata. Come sempre, grazie per l'ascolto. Ci vediamo al prossimo episodio.

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 5 di 14. Gli sviluppatori spesso creano Personal Access Token a lunga scadenza per le attività di base sul repository, lasciando credenziali permanenti nella loro codebase. Ma per la maggior parte delle interazioni con GitHub, non hai affatto bisogno di creare un token: c'è un token sicuro ed effimero che ti aspetta in ogni job. Questo è l'argomento dell'episodio di oggi: Il confine della sicurezza: secret e GITHUB_TOKEN. Quando avvii un workflow, GitHub genera automaticamente un secret univoco chiamato GITHUB_TOKEN. Non si tratta di un normale Personal Access Token. Funziona come un installation access token di breve durata per una GitHub App. Esiste esclusivamente per la durata del job del workflow. Nel momento in cui il job termina, o dopo un massimo di 24 ore, il token scade e diventa completamente inutilizzabile. Un errore comune è generare un Personal Access Token permanente solo per far sì che un workflow aggiunga una label a un'issue o pubblichi un commento su una pull request. Questo amplia inutilmente la tua superficie di attacco. Il GITHUB_TOKEN integrato possiede già i permessi necessari per interagire con il repository che ha triggerato il workflow. Se il tuo job deve aggiungere una label a un'issue, passi questo token integrato allo step che esegue la chiamata API. Non viene mai creata, memorizzata o esposta alcuna credenziale permanente. Questo copre l'interazione con GitHub stesso. Ma il tuo workflow dovrà inevitabilmente comunicare con il mondo esterno. È qui che entrano in gioco i secret crittografati personalizzati. Quando crei un secret personalizzato, questo non risiede in plain text su un server GitHub. Il valore viene crittografato localmente utilizzando una sealed box di Libsodium prima ancora di essere trasmesso. La crittografia si basa sulla crittografia a chiave pubblica. Quando aggiungi un secret tramite l'interfaccia web o l'API, GitHub fornisce una chiave pubblica. Il tuo client utilizza quella chiave per sigillare la box. Solo la macchina virtuale isolata del runner possiede la chiave privata corrispondente necessaria per aprire quella box, e decripta il payload solo nel momento esatto in cui il job viene eseguito. Puoi definire questi secret crittografati a diversi livelli a seconda della tua architettura. I secret a livello di repository si applicano a una singola codebase. I secret a livello di organization ti permettono di condividere una singola credenziale, come la password di un database di produzione, tra più repository. Questo centralizza la gestione delle credenziali, ma richiede un controllo rigoroso. I secret di organization utilizzano access policy in cui definisci esplicitamente quali repository sono autorizzati a leggere il secret. Mettiamo che tu abbia una password del database a livello di organization necessaria per uno step di migrazione del database. Non vuoi che questa password sia accessibile all'intero workflow. GitHub Actions impone un confine di sicurezza rigoroso in questo caso. I secret non vengono iniettati automaticamente nell'environment di ogni step. Devi mappare esplicitamente il secret a una environment variable nello step specifico che lo richiede. Quando scrivi il file del workflow, accedi al valore crittografato utilizzando una specifica context reference, richiamandolo dal secrets object, e lo assegni a una environment variable locale. Poiché l'hai mappato esplicitamente, lo step precedente alla migrazione non può vedere la password, e nemmeno lo step successivo. Ecco il punto chiave. La sicurezza nell'automazione si basa sulla minimizzazione della durata e sulla limitazione dello scope. Affidati all'effimero GITHUB_TOKEN per le azioni interne al repository, in modo da evitare di gestire credenziali permanenti, e mappa rigorosamente i secret crittografati solo ai singoli step che richiedono l'accesso esterno. Questo è tutto per oggi. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 6 di 14. Imposti un workflow multi-job e, per assicurarti che il secondo job abbia tutto quello che gli serve, impacchetti l'intera cartella delle dipendenze e gliela passi. Ma all'improvviso, la tua build ci mette cinque minuti in più e l'utilizzo dello storage schizza alle stelle. Il problema è un fraintendimento di fondo tra due meccanismi di dati ben distinti, ed è esattamente quello che copriremo in questo episodio: Ottimizzare i dati: Caching vs Artifact. Chiariamo subito questa confusione. Sia il caching che gli artifact spostano file tra i tuoi runner di GitHub Actions, ma risolvono problemi completamente diversi. Pensa agli artifact come a ciò che il tuo workflow produce. Pensa al caching come a ciò che il tuo workflow consuma. Se inverti questi ruoli, creerai silenziosamente un collo di bottiglia per l'intera pipeline. Gli artifact sono file generati che vuoi conservare quando un job finisce. Potrebbe essere un binario compilato, un report di test coverage, o un archivio zip della tua directory di build finale. Esistono per due motivi principali. Primo, per permetterti di scaricare l'output finale del tuo workflow una volta completato. Secondo, per passare i dati generati tra job diversi all'interno della stessa identica run del workflow. Dato che ogni job gira su una virtual machine pulita, qualsiasi file creato nel job uno viene perso all'istante quando quel job finisce, a meno che tu non ne faccia esplicitamente l'upload. Usando l'action di upload artifact, salvi quei file nello storage di GitHub. Poi, il job due usa l'action di download artifact per tirarli dentro il suo workspace pulito. Ora, confrontalo con il caching delle dipendenze. Il caching è puramente un'ottimizzazione delle performance, pensata per velocizzare il tuo workflow tra diverse run nel tempo. Quando fai la build di un software, di solito scarichi migliaia di dipendenze di terze parti, come pacchetti da NPM o pip. Recuperarle dalla rete a ogni singola run è lento. Invece di scaricare dipendenze nuove ogni volta, l'action di cache salva la tua cartella delle dipendenze scaricate sui server di cache. Assegna a questa cache una chiave univoca, quasi sempre basata sull'hash del tuo lock file. Nella run del workflow di domani, GitHub controlla se il lock file corrisponde a una chiave esistente. Se corrisponde, ripristina la cartella direttamente nel tuo runner in pochi secondi, bypassando completamente il package registry. Ecco il punto chiave. L'errore più grande che puoi fare è usare l'action di upload artifact per spostare un'enorme cartella di dipendenze, come node modules, tra i job. Gli artifact processano i dati zippandoli, facendone l'upload, il download e unzippandoli. Farlo con decine di migliaia di piccoli file di testo aggiunge un'enorme latenza di rete al tuo tempo di run e consuma le quote di storage del tuo account. Gli artifact non sono pensati per la velocità pura; sono pensati per il trasferimento sicuro dei dati e per la conservazione permanente. Le cache, d'altra parte, sono altamente ottimizzate per tirare giù rapidamente alberi di dipendenze pesanti, e invecchiano e si eliminano automaticamente per risparmiare spazio. Immagina una pipeline adeguata che li usa entrambi correttamente. Hai un workflow con un job di build e un job di deploy. Nel job di build, il tuo primo step usa l'action di cache per ripristinare all'istante le tue dipendenze NPM dalla run di ieri. Il tuo codice compila velocemente, producendo un binario finale dell'applicazione. A quel punto usi l'action di upload artifact per salvare solo quel singolo file binario. Il job di build finisce, e il runner viene distrutto. Il job di deploy si avvia su un nuovo runner. Non ha bisogno della cache, e non ha bisogno delle dipendenze NPM. Usa semplicemente l'action di download artifact per recuperare il binario compilato che hai appena buildato, e poi fa il push sul tuo server di produzione. Il caching è una scorciatoia usa e getta per le cose che scarichi, mentre gli artifact sono il passaggio di consegne essenziale per le cose che crei. Grazie per avermi fatto compagnia. Spero che tu abbia imparato qualcosa di nuovo.

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 7 di 14. Uno sviluppatore fa tre commit in rapida successione su una pull request aperta in cinque minuti. Se il tuo server CI sta eseguendo tre test suite ridondanti, stai bruciando soldi. Hai bisogno di un modo per dire al sistema che conta solo il codice più recente, ed è esattamente quello che fai controllando il flusso con la concurrency. Di default, GitHub Actions esegue i workflow triggerati in parallelo. Se fai cinque push, avvia cinque runner indipendenti. Per i controlli di base, questo spreca i minuti dei runner. Per i deploy, è davvero pericoloso. Se due run del workflow provano a fare il deploy contemporaneamente nello stesso ambiente di staging, crei una race condition. Il commit più vecchio potrebbe persino finire il deploy dopo quello più nuovo, sovrascrivendo i tuoi aggiornamenti e lasciando l'ambiente in uno stato obsoleto. Risolvi questo problema usando la keyword concurrency. Puoi applicarla al top level dell'intero workflow o limitarla a un job specifico. Il meccanismo si basa interamente sui concurrency group. Un concurrency group è semplicemente una stringa che definisci tu. Se due run condividono esattamente lo stesso nome del gruppo, GitHub impone dei limiti di concurrency tra di loro. Molti fanno l'errore di hardcodare questa stringa. Se imposti il nome del gruppo solo con la parola deploy, allora fare un push sul tuo branch di testing cancellerà un deploy attivo sul tuo branch di produzione main. Il nome del gruppo deve essere dinamico. Lo costruisci usando le variabili di context, come la reference al branch corrente. Se dai al gruppo il nome usando il numero della pull request, allora i limiti di concurrency si applicano solo ai push all'interno di quella specifica pull request. Il tuo branch main rimane completamente inalterato. Quando viene triggerato un nuovo workflow, GitHub controlla se c'è già una run attiva per quel concurrency group. Se c'è, il comportamento di default è mettere la nuova run in uno stato pending. Aspetta in una coda. Ecco il punto chiave. La coda contiene un solo job in pending. Se viene triggerata una terza run mentre la prima è in esecuzione e la seconda è in pending, la seconda run viene espulsa dalla coda. Solo l'ultima run in assoluto si mette in attesa. Aspettare è più sicuro per i deploy, ma per i test delle pull request, l'attesa consuma comunque tempo inutile. È qui che entra in gioco l'impostazione cancel-in-progress. È un boolean flag che aggiungi sotto la definizione del tuo concurrency group. Quando imposti cancel-in-progress su true, cambi il comportamento dall'accodamento alla terminazione. Torna allo sviluppatore che fa tre commit in rapida successione. Il primo push triggera una test suite. Due minuti dopo, fa un altro push. Dato che hai impostato il concurrency group sul nome del branch e hai abilitato cancel-in-progress, GitHub vede la nuova run, termina all'istante la test suite attiva per il primo commit e inizia a testare il secondo commit. Quando avviene il terzo push un minuto dopo, termina la seconda run e avvia la terza. Lo sviluppatore ottiene comunque il pass o fail finale, ma tu hai pagato per eseguire i test una volta sola. I controlli di concurrency trasformano le tue pipeline CI da un sistema reattivo che esegue ciecamente ogni trigger in un sistema state-aware che spende risorse solo sul codice che conta davvero. Grazie per aver ascoltato, buon coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 8 di 14. Le credenziali del tuo database di production non dovrebbero mai essere accessibili a una pull request casuale da un feature branch. Eppure, se tutti i tuoi secret sono archiviati a livello di repository, qualsiasi workflow può potenzialmente impossessarsene. Risolvere questa falla di sicurezza è esattamente il motivo per cui hai bisogno di fare gating dei deployment con gli environment. Innanzitutto, dobbiamo chiarire un equivoco comune. Un environment in GitHub Actions non è un server fisico. GitHub non crea una macchina virtuale o un'istanza cloud chiamata production per te. Un environment è semplicemente un confine logico configurato nelle impostazioni del tuo repository GitHub. Agisce da gatekeeper, controllando quando un job può essere eseguito e quali dati quel job può vedere. Il motivo principale per cui esiste questa funzionalità è garantire la governance delle release e proteggere i dati sensibili. Quando crei un environment, puoi associarvi direttamente secret e variabili specifici. Potresti creare un environment chiamato staging e un altro chiamato production. Ognuno ottiene un set univoco di chiavi API, memorizzate esattamente con lo stesso nome di variabile. Nel file del tuo workflow, colleghi un job specifico a un environment semplicemente indicandone il nome. Quando il workflow viene eseguito, il job che fa riferimento all'environment di staging ottiene le chiavi di staging. Il job che fa riferimento all'environment di production ottiene le chiavi di production. Questo isola completamente i tuoi dati sensibili. Un job in esecuzione in un feature branch non può leggere le chiavi di production perché non viene eseguito nel contesto dell'environment di production. Ma isolare i secret è solo metà della potenza degli environment. L'altra metà sono le protection rule. Queste regole agiscono come rigidi gate nella tua pipeline di deployment. La protection rule più comune è il required reviewer. Vediamo come funziona in uno scenario reale. Hai un workflow che compila la tua applicazione e ne fa automaticamente il deploy in staging. Quel job ha successo. Il job immediatamente successivo nel workflow è configurato per fare il deploy in production, e fa riferimento al tuo environment di production. Se hai impostato una regola di required reviewer per quell'environment, il workflow si ferma proprio lì. Il job va in pausa. Non viene inviato a un runner, e le chiavi API di production rimangono chiuse al sicuro. GitHub invia una notifica al manager o al team designato, indicando che un deployment è in attesa. Il workflow rimarrà in questo stato pending finché non verrà intrapresa un'azione. Solo quando il manager clicca su approve nell'interfaccia di GitHub, il gate si apre. In quel preciso istante, il job viene inviato a un runner disponibile, i secret di production vengono decriptati e iniettati, e lo script di deployment viene eseguito. Puoi aggiungere altre protection rule oltre alle approvazioni manuali. Un'opzione è un wait timer, che forza un job a ritardare per un numero specificato di minuti prima di iniziare. Questo ti dà un margine di tempo per annullare un rollout se noti un picco di errori nelle tue dashboard di monitoraggio subito dopo un deployment in staging. Puoi anche configurare i deployment branch. Questo limita l'environment in modo che accetti solo job eseguiti da branch specifici, come il tuo main branch o specifici release tag. Se uno sviluppatore tenta di forzare un job di deployment in production da un bugfix branch casuale, il gate dell'environment semplicemente rifiuta la run. Ecco il punto chiave. Gli environment disaccoppiano i tuoi meccanismi di deployment dal controllo degli accessi. Il tuo file di workflow descrive i passaggi esatti necessari per fare il deploy del tuo codice, ma le impostazioni dell'environment in GitHub determinano chi ha l'autorità per consentirlo e quali secret vengono sbloccati quando lo fanno. Se apprezzi questi approfondimenti tecnici, puoi supportare il podcast cercando DevStoriesEU su Patreon. Grazie per l'ascolto, buon coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 9 di 14. La credenziale cloud più sicura è quella che scade cinque minuti dopo la fine del tuo deployment. Eppure, molti team continuano a copiare chiavi di amministratore a lunga durata nei settings del repository, sperando che non vengano mai esposte. Oggi risolviamo questo problema dando un'occhiata al Passwordless Cloud Access tramite OIDC. Storicamente, connettere un workflow di GitHub a un cloud provider significava generare un'access key in AWS, Google Cloud o Azure, e salvarla come GitHub Secret a lunga durata. Se quel secret veniva esposto, chiunque poteva usarlo da ovunque finché un amministratore non lo revocava manualmente. Spesso si pensa che OpenID Connect, o OIDC, sia solo un nuovo tipo di secret da incollare nel tuo repository. Non è così. OIDC sostituisce completamente i secret salvati. È un protocollo che genera un token crittografico dinamico al volo per dimostrare l'identità del workflow al tuo cloud provider. GitHub funge da OIDC Identity Provider. Quando un workflow gira, può richiedere a GitHub di emettere un JSON Web Token, o JWT. Per farlo, devi aggiungere una permission specifica al tuo file di workflow. Imposti il blocco permissions per consentire l'accesso in scrittura per l'ID token. Questo dice a GitHub che il workflow è autorizzato a generare una credenziale di identità. Ecco il punto chiave. Questo token non concede l'accesso di per sé. È semplicemente un documento firmato digitalmente che contiene dei claim. I claim sono pezzi di metadati che dichiarano fatti verificabili sul workflow attualmente in esecuzione. Il token include il nome del repository, l'organizzazione, il branch, l'environment e l'evento che ha triggerato la run. Dato che GitHub firma crittograficamente il token, il tuo cloud provider può fidarsi di questi claim. Questo costituisce la base di un deployment zero-trust. Guardiamo un job di deployment che pusha una container image su un AWS Elastic Container Registry. Il workflow parte e richiede un token OIDC a GitHub. Il token viene generato, contenendo claim che verificano che provenga dal branch main del tuo repository backend. Il workflow poi invia questo token ad AWS. AWS per prima cosa verifica la firma digitale per assicurarsi che il token provenga effettivamente da GitHub. Poi, legge i claim. Controlla questi claim rispetto a una rigida trust policy che hai definito in precedenza. La policy potrebbe dire che accetta token solo dal tuo repository specifico e solo se il workflow sta girando sul branch main. Dato che i claim corrispondono, AWS accetta il token. AWS non restituisce una chiave permanente. Invece, emette un access token temporaneo. Questo token potrebbe essere valido per soli quindici minuti. Il tuo workflow usa questa credenziale temporanea per pushare la container image sul registry. Quando il job finisce, la credenziale scade. Non c'è nulla da ruotare, e non c'è nulla di salvato in GitHub che un attaccante potrebbe estrarre. Quando configuri tutto questo, fai molta attenzione al subject claim, spesso chiamato sub claim. Questo è il campo principale che i cloud provider usano per filtrare l'accesso. Di default, GitHub formatta il subject claim per includere il nome del repository e la git reference, come il branch o il tag. Devi assicurarti che la tua cloud trust policy validi rigorosamente questo subject claim. Se controlli solo il nome dell'organizzazione, qualsiasi repository nella tua organizzazione potrebbe richiedere risorse cloud. Collegando l'accesso cloud temporaneo a metadati specifici del workflow, garantisci che un repository compromesso non possa toccare la tua infrastruttura a meno che la richiesta non provenga esattamente dal branch e dall'environment di cui ti fidi esplicitamente. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 10 di 14. Quando gestisci la continuous integration su cinquanta repository, copiare e incollare lo stesso identico YAML è un incubo di manutenzione annunciato. Cambi un tool di security scanning e all'improvviso devi aggiornare a mano cinquanta file separati. Questo episodio parla di come scalare le pipeline DRY per risolvere esattamente questo problema. Per smettere di ripeterti in GitHub Actions, hai a disposizione due tool principali. I Reusable Workflow e le Composite Action. Spesso gli ingegneri scelgono quello sbagliato perché entrambi evitano la duplicazione. Una Composite Action non è un workflow. È semplicemente un insieme di step. Un Reusable Workflow è una pipeline completa che raggruppa interi job. Se la tua logica condivisa deve estendersi su più macchine, orchestrare dipendenze complesse tra i job o gestire i secret in modo sicuro, devi usare un Reusable Workflow. Una Composite Action prende una sequenza di step, come fare il checkout del codice, configurare l'ambiente di un linguaggio e installare le dipendenze, e li impacchetta in un'unica custom action. Quando un workflow usa questa action, tutti quegli step raggruppati vengono eseguiti in sequenza all'interno del job corrente già esistente. La Composite Action non decide su quale macchina runner girare. Gira ovunque il job padre la collochi. Esiste puramente per ripulire la logica ripetitiva degli step all'interno di un singolo ambiente di esecuzione. I Reusable Workflow operano a un livello architetturale molto più alto. Sono file YAML completi che un altro workflow può triggerare. Il workflow che fa la richiesta è il caller workflow, e il workflow che viene triggerato è il called workflow. Dato che un called workflow definisce interi job, controlla l'infrastruttura. Un job all'interno del Reusable Workflow potrebbe girare su un runner Ubuntu per fare la build di un'applicazione, mentre un job dipendente gira su un runner macOS per testarla. Prendi un team di Platform Engineering che sta standardizzando una pipeline di deploy Node. Vogliono assicurarsi che ogni team esegua security check identici prima di rilasciare il codice. Invece di fidarsi che cinquanta team di prodotto mantengano file YAML identici, i platform engineer creano un singolo Reusable Workflow centrale in un repository condiviso. Questo file centrale definisce l'esatta sequenza di job necessari per scansionare, fare la build e il deploy dell'applicazione. I cinquanta repository di prodotto creano quindi un caller workflow minimale. Questo caller workflow contiene un solo job che punta direttamente al file condiviso del platform team usando il suo path. Passi i dati di configurazione al called workflow usando gli input, specificando parametri come il nome dell'ambiente di destinazione o la versione di Node. Il caller workflow può anche passare dei secret. Puoi mappare esplicitamente dei secret specifici, o istruire il called workflow a ereditare semplicemente tutti i secret disponibili per il caller. Quando il platform team deve ruotare un secret di deploy o aggiungere un nuovo tool di analisi statica, aggiorna il called workflow centrale. All'istante, tutti e cinquanta i repository eseguono il nuovo security check al loro prossimo commit. I team di prodotto toccano zero configurazioni. Ecco il punto chiave. Usa le Composite Action per nascondere la logica disordinata degli step all'interno di un singolo ambiente, ma usa i Reusable Workflow per imporre architetture di pipeline standardizzate in tutta la tua organizzazione. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 11 di 14. Un container garantisce versioni precise dei tool, ma comporta un costo nascosto in termini di latenza per ogni singola esecuzione del workflow. La coerenza del tuo ambiente potrebbe rallentare il tuo team e vincolarlo a un singolo sistema operativo senza che tu te ne accorga. Creare Custom Actions: Docker vs JavaScript risolve questo problema. Una custom action è una logica riutilizzabile che scrivi una sola volta e condividi tra più repository. Quando ne crei una, devi scegliere un'architettura di esecuzione. I due modelli principali sono JavaScript e Docker. Molti ingegneri optano di default per le Docker actions perché vogliono la massima sicurezza e dipendenze prevedibili. Danno per scontato che un container sia la scelta più robusta. La realtà è che creare una Docker action impedisce permanentemente a qualsiasi runner macOS o Windows di utilizzare il tuo tool. Le Docker actions vengono eseguite solo in ambienti Linux. Le JavaScript actions adottano un approccio diverso. Vengono eseguite direttamente sulla macchina host. Scrivi la tua logica, la compili in un singolo file con tutte le sue dipendenze e punti i metadati della action a quell'entry file. Quando un workflow viene triggerato, il runner utilizza il suo runtime Node integrato per eseguire il tuo script. Questo disaccoppia la tua logica dal sistema operativo sottostante. La stessa identica action girerà nativamente sui runner Linux, macOS e Windows senza modifiche. Le Docker container actions, al contrario, impacchettano il sistema operativo, le dipendenze di sistema e il tuo codice in un'unità immutabile. Sei tu a definire l'ambiente esatto. Il runner legge un Dockerfile fornito dalla tua action, fa la build o il pull dell'immagine del container ed esegue il tuo codice all'interno di quello spazio isolato. Ecco il punto chiave. Il rigoroso isolamento di una Docker action introduce una penalità di cold-start. Immagina un team che crea un tool di code linting custom da condividere all'interno dell'organizzazione. Se lo creano come Docker action, il runner deve fare il pull di quell'immagine del container prima di poter valutare una singola riga di codice. Questo potrebbe aggiungere un ritardo di quindici secondi all'avvio di ogni job di linting. Su centinaia di pull request al giorno, questo tempo di inattività si accumula in ore di compute sprecato. Se il team implementa la stessa identica logica di linting in JavaScript, il runner scarica semplicemente lo script file e lo esegue all'istante. La tua scelta dell'architettura determina il comportamento della tua action nel mondo reale. Se il tuo tool si basa su system binaries complessi, richiede una versione molto specifica di un compiler, o wrappa dei Bash scripts legacy che sono fragili al di fuori di una specifica distribuzione Linux, Docker è la scelta corretta. Paghi la tassa della latenza in cambio di una stabilità garantita. Se il tuo obiettivo è creare un tool veloce e ampiamente adottato che funzioni con qualsiasi tipo di progetto, JavaScript è la strada migliore. La scelta architetturale tra Docker e JavaScript per una custom action non riguarda mai il linguaggio di programmazione in cui preferisci scrivere, è un duro trade-off tra un rigoroso controllo dell'ambiente e la velocità di esecuzione cross-platform. Questo è tutto per oggi. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 12 di 14. I runner cloud di GitHub sono estremamente comodi, finché i tuoi integration test non devono accedere a un database legacy nascosto in modo sicuro dietro un firewall aziendale. All'improvviso, un runner pubblico non riesce a raggiungere i tuoi dati privati. È proprio qui che entra in gioco il Fleet Management: runner hosted contro runner self-hosted. Di default, GitHub Actions usa runner hosted da GitHub. Quando un workflow viene triggerato, GitHub avvia una nuova macchina virtuale. Puoi richiedere Ubuntu, Windows o macOS. Il runner esegue il tuo job, riporta il risultato, e poi la macchina virtuale viene immediatamente distrutta. È un ambiente pulito ogni singola volta. Non devi gestire il sistema operativo, non installi patch di sicurezza e non ti preoccupi dei file residui di una build precedente. Tuttavia, questo isolamento è un'arma a doppio taglio. Poiché questi runner si trovano nell'infrastruttura cloud di GitHub, operano con indirizzi IP dinamici e non hanno accesso diretto alle tue reti private. Se hai un'applicazione interna, o un database che non può essere esposto su internet pubblico, hai bisogno di un runner che viva all'interno del tuo perimetro di sicurezza. Questo è un runner self-hosted. Fornisci tu l'hardware. Può essere un server fisico in un data center, una macchina virtuale nel tuo cloud provider, o un container. Installi l'applicazione GitHub Actions runner su quella macchina. Il runner si connette verso l'esterno a GitHub, recupera i job in sospeso, li esegue in locale e rimanda i log. Dato che si trova sulla tua rete, può comunicare in modo sicuro con la tua infrastruttura interna senza dover aprire buchi nel firewall. Ecco il punto chiave. Possiedi l'hardware, il che significa che la manutenzione spetta a te. Sei responsabile degli aggiornamenti del sistema operativo, della sicurezza di rete e dell'installazione delle dipendenze necessarie, come i runtime dei linguaggi o i build tool. Un malinteso comune è pensare che i runner self-hosted si comportino esattamente come quelli hosted. Non è così. I runner hosted da GitHub sono effimeri by design. I runner self-hosted standard sono stateful. Quando un job finisce su un runner self-hosted di default, la macchina rimane in esecuzione. Se il tuo job scrive un file temporaneo, avvia un processo in background o fa il pull di una grossa immagine container, tutto questo rimane sul disco quando inizia il job successivo. Questo crea seri rischi di cross-contamination. Uno script di build difettoso in una pull request potrebbe lasciare indietro file corrotti, facendo fallire il job di deployment che gira subito dopo. Devi configurare attivamente la tua infrastruttura self-hosted per essere effimera se è quello che vuoi, spesso usando dei webhook per avviare nuovi container per ogni job. Se hai semplicemente bisogno di più potenza di calcolo o di un indirizzo IP statico, ma vuoi comunque che GitHub gestisca la manutenzione della macchina, c'è una via di mezzo chiamata larger runner. Si tratta di macchine hosted da GitHub in cui sei tu a definire le specifiche hardware e le feature di rete, ma rimangono effimere e gestite da GitHub. Alla fine, la decisione tra hosted e self-hosted raramente riguarda solo i costi di compute. È un trade-off fondamentale tra la comodità di un ambiente usa e getta a zero manutenzione e la necessità di controllare i confini della tua rete. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 13 di 14. Hai un team enorme e alle nove del mattino un centinaio di sviluppatori fanno push del codice contemporaneamente. I tuoi server di build statici o si ingolfano sulla queue, oppure li hai sovradimensionati e restano lì a sprecare costoso compute per tutta la notte. Kubernetes Scale: Actions Runner Controller risolve questo problema trasformando la tua build pipeline in un sistema dinamico e container-native. I runner self-hosted standard sono solitamente macchine virtuali statiche o long-lived container. Li configuri, li registri a un repository e restano lì a fare polling in attesa di lavoro. Questa configurazione garantisce che tu stia pagando per l'idle time e, quando arriva un picco improvviso di build, la tua queue semplicemente si intasa finché un runner esistente non finisce il suo task corrente. Actions Runner Controller, o ARC, cambia radicalmente questo modello. ARC è un Kubernetes operator che orchestra runner scale set in auto-scaling. Invece di mantenere long-lived worker node, fa il provisioning di runner effimeri, Just-in-Time, basati sulla dimensione esatta della tua queue. Per riuscirci senza saturare gli API rate limit, ARC si basa su due componenti architetturali principali all'interno del tuo cluster Kubernetes. Il primo è il pod Listener. Il Listener usa un long poll HTTPS per connettersi a GitHub. Invece di chiederti di aprire porte inbound sul firewall per ricevere webhook, il Listener contatta GitHub e tiene aperta la connessione. Resta lì, in attesa silenziosa che GitHub gli passi un messaggio di Job Available. Quando il Listener riceve quel messaggio, passa l'informazione al pod Controller. Il Controller fa da provisioning engine. Parla immediatamente con le API di Kubernetes per fare lo spin up di un pod runner nuovo di zecca, specifico per quel singolo job in pending. Questo pod è un runner effimero Just-in-Time. Fa il boot, riceve un registration token di breve durata, esegue il workflow e poi si termina immediatamente. Torniamo a quel rush di codice delle nove del mattino. Cento sviluppatori fanno push di commit esattamente nello stesso momento. Il pod Listener rileva l'improvviso burst di messaggi Job Available da GitHub. Avvisa il Controller, che richiede immediatamente cento pod Kubernetes effimeri. Il tuo cluster fa scale out, allocando nodi se necessario, e i job vengono eseguiti in parallelo. Man mano che ogni workflow finisce, il suo pod viene completamente distrutto. Alle nove e un quarto, la queue è vuota e il numero dei tuoi runner fa scale down fino a zero. Hai usato un enorme compute parallelo per esattamente quindici minuti, e poi hai smesso di pagarlo. Ecco il punto chiave. Dato che ogni singolo job gira in un pod isolato, appena provisionato e distrutto subito dopo l'esecuzione, elimini completamente la contaminazione di stato tra le build. Una cache sporca, un background process rimasto appeso o un'environment variable modificata da una run precedente, semplicemente non possono rompere quella successiva. Ottieni la sicurezza di un build environment immacolato ogni volta, unita all'esatta efficienza di compute dell'auto-scaling di Kubernetes. Il vero valore dell'Actions Runner Controller è che ti impedisce di trattare i runner di continuous integration come un'infrastruttura pesante che devi mantenere, trasformandoli invece in compute puramente transitorio che esiste solo mentre un job è attivamente in esecuzione. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. GitHub Actions, episodio 14 di 14. Un utente scarica il tuo command line tool compilato da una pagina di release. Se una dependency compromessa o un malintenzionato ha sostituito quel binary dopo la build, un controllo di checksum standard non lo salverà. Gli hash standard dimostrano solo che il file scaricato corrisponde al file hostato, non la sua effettiva provenienza. Per garantire che un file sia stato generato esattamente dal tuo codice, hai bisogno della Supply Chain Integrity con le Attestations. Un'attestation non è semplicemente un build log o un file di testo contenente un hash accanto alla tua release. È una dichiarazione crittograficamente firmata e non falsificabile sulla provenienza di un artifact. Collega il tuo binary finale direttamente all'esatto commit SHA, alla specifica workflow run e all'identità OpenID Connect dell'ambiente di build. L'intero processo avviene all'interno del tuo workflow di GitHub Actions. Dopo che il tuo codice è stato compilato, utilizzi l'action ufficiale di build provenance. Questa action calcola il checksum del tuo artifact finale e contatta un'autorità di firma centralizzata, nello specifico Sigstore. Il workflow scambia il suo token OpenID Connect temporaneo e specifico per il job con un certificato di firma di breve durata. Poiché questo token viene generato da GitHub Actions e mappato direttamente al tuo repository, funge da carta d'identità infalsificabile per il workflow runner. Questa interazione genera un record crittografico permanente. Questo record attesta inequivocabilmente che questo preciso hash del file è stato prodotto dal tuo repository, triggerato da uno specifico commit, durante una specifica workflow run. La firma viene allegata all'artifact, creando un insieme di prove che accompagna il file ovunque venga hostato. Ecco il punto chiave. Il vero valore in termini di sicurezza si manifesta lato consumer. Quando un utente scarica il tuo command line tool, non deve fidarsi ciecamente dell'hosting provider o del download mirror. Prima di eseguire il binary, utilizza la GitHub CLI per verificare localmente l'attestation. Esegue un comando di attestation verify sull'eseguibile scaricato, specificando esplicitamente il proprietario del repository come fonte prevista. La CLI analizza la firma crittografica e la confronta con il transparency log pubblico. Se la firma è valida, dimostra matematicamente che il file è stato compilato dal tuo workflow ufficiale. Se un malintenzionato intercettasse il download, manomettesse la build o sostituisse il binary sulla pagina di release, la verifica fallirebbe immediatamente. La firma non può essere falsificata perché l'attaccante non potrà mai possedere il token di identità temporaneo OpenID Connect generato all'interno della tua workflow run sicura. L'identità è indissolubilmente legata all'infrastruttura di GitHub Actions nel momento esatto della build. Questo meccanismo colma una lacuna critica nella sicurezza della software supply chain. Non stai più chiedendo agli utenti di fidarsi di una storage location. Al contrario, l'artifact diventa auto-autenticante. Le Attestations spostano il tuo modello di sicurezza dal fidarsi di dove risiede un file al dimostrare matematicamente dove è nato. Dato che questo è l'ultimo episodio della nostra serie su GitHub Actions, ti incoraggio vivamente a metterti all'opera e iniziare a creare questi workflow da solo. Visita devstories dot eu per suggerire argomenti che vorresti vedere trattati nelle nostre prossime serie. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!