Impara a automatizzare build, test e deployment utilizzando GitHub Actions. Questa guida spiega come configurare il primo workflow tramite interfaccia web, gestire i file YAML e interpretare i risultati dei job.
Precisati i tempi di esecuzione dei workflow e la condivisione dei dati fra step e job.
GitHub Actions è una piattaforma di continuous integration e continuous delivery (CI/CD), ovvero un sistema che permette di automatizzare l'intera pipeline di costruzione, test e distribuzione del software. Il problema principale che risolve è l'eliminazione dei processi manuali ripetitivi: invece di testare il codice a mano prima di ogni rilascio, è possibile creare workflow che eseguono queste operazioni automaticamente ogni volta che viene effettuato un push o un merge di una pull request nel repository. [1][2]
Il risultato è un controllo ripetibile delle modifiche al codice: il workflow avvia le operazioni previste quando si verifica un evento configurato. Il responso arriva al termine dei job, quindi l’avvio automatico non equivale a una validazione istantanea. Oltre al classico DevOps, lo strumento permette di reagire a eventi generici del repository, come l'apertura di una nuova issue, attivando azioni automatiche come l'assegnazione di etichette specifiche, rendendo la gestione del progetto più efficiente e meno soggetta a errori umani. [2]
Per iniziare a utilizzare GitHub Actions è necessario possedere un repository su GitHub in cui sia possibile aggiungere file e avere i permessi di accesso alle funzionalità di Actions. È fondamentale che la scheda Actions sia abilitata nelle impostazioni del repository; in caso contrario, l'interfaccia di gestione non sarà visibile sotto il nome del progetto, impedendo la configurazione dei processi di automazione. [1]
Dal punto di vista delle competenze, è richiesta una conoscenza di base della gestione dei repository e delle pull request. Sebbene GitHub offra template preconfigurati che analizzano il codice (ad esempio suggerendo workflow specifici per progetti Node.js), è essenziale comprendere che i workflow sono definiti tramite file in formato YAML, un linguaggio di markup standard per i file di configurazione, che devono essere salvati in una directory specifica per essere riconosciuti dal sistema. [1]
Dal trigger all'esecuzione dei job sui runner
Il primo passo operativo consiste nel creare un file di configurazione chiamato github-actions-demo.yml. Questo file deve essere posizionato obbligatoriamente all'interno della directory .github/workflows. Se tale cartella non esiste, è possibile crearla direttamente dall'interfaccia web di GitHub selezionando Add file e poi Create new file, inserendo il percorso completo .github/workflows/github-actions-demo.yml nel campo del nome file. [1]
Una volta creato il file, è necessario inserire il codice YAML che definisce il comportamento dell'automazione. Un esempio illustrativo di configurazione prevede la definizione di un nome per il workflow, l'indicazione dell'evento di trigger (come il push) e la specifica del runner, ovvero il server che eseguirà il lavoro (ad esempio ubuntu-latest). All'interno del job, vengono definiti gli step, che possono essere semplici comandi echo per stampare messaggi o l'utilizzo di action predefinite come actions/checkout@v6 per clonare il codice del repository sul runner. [1]
Dopo aver incollato il contenuto YAML, l'utente deve procedere al salvataggio cliccando su Commit changes. In questa fase, GitHub presenta un dialogo Propose changes dove è possibile scegliere se applicare il commit direttamente al branch predefinito o creare un nuovo branch per avviare una pull request. Entrambe le opzioni sono valide per l'attivazione del workflow, poiché l'evento di push è ciò che scatena l'esecuzione automatica del processo definito nel file .yml. [1]
È importante notare che l'azione di commit non è solo un salvataggio di dati, ma funge da trigger operativo. Se l'utente sceglie la via della pull request, il workflow verrà comunque avviato non appena il commit viene registrato sul branch, rendendo superflua la chiusura immediata della pull request per scopi di test rapido del sistema di automazione. [1]
Per verificare che il workflow sia stato eseguito correttamente, occorre navigare nella pagina principale del repository e cliccare sulla scheda Actions. Da qui, è possibile selezionare il workflow specifico (ad esempio GitHub Actions Demo) e successivamente cliccare sul nome della singola esecuzione (run) per accedere ai dettagli. Nella barra laterale sinistra, sotto la sezione Jobs, è necessario selezionare il job specifico, come Explore-GitHub-Actions, per visualizzare l'andamento dell'operazione. [1]
La verifica concreta del risultato avviene attraverso l'analisi dei log: ogni step del job può essere espanso per visualizzare l'output testuale generato dal runner. Ad esempio, se il workflow include un comando per elencare i file del repository, l'espansione di quello step permetterà di vedere l'elenco effettivo dei file presenti nel workspace del runner, confermando che il codice è stato clonato correttamente e che l'ambiente di esecuzione è operativo. [1]
Sui runner gestiti da GitHub, l’ambiente di esecuzione del job è una macchina virtuale appena predisposta. Gli step dello stesso job possono condividere i dati perché lavorano sullo stesso runner: per esempio, uno step costruisce l’applicazione e quello successivo verifica il risultato. Non conviene estendere questa condivisione ai job distinti. Di norma i job non hanno dipendenze reciproche e partono in parallelo; quando serve un ordine, il workflow deve dichiarare le dipendenze fra i job. [2]
La scelta del runner dipende anche dal sistema operativo e dalle risorse necessarie. GitHub offre runner Ubuntu, Windows e macOS, oltre a configurazioni più grandi. Se il lavoro richiede un sistema operativo diverso o un hardware specifico, si può ricorrere a un runner self-hosted: la macchina è gestita da chi la mette a disposizione e va predisposta per eseguire i workflow. Per il primo esempio di questa guida, partire dal runner indicato nel file permette di concentrarsi sui log e sull’esecuzione degli step. [2]
Guida tecnica all'installazione e configurazione di Myna, il sistema di dettatura locale per Ubuntu che permette di trascrivere l'audio in tempo reale senza l'invio di dati a server esterni.
Guida tecnica all'uso degli audiolibri su Spotify in Italia: gestione delle 12 ore mensili, costi di Audiolibri+, funzionamento di Page Match e limiti dei piani Family e Student.
Microsoft introduce l'archiviazione cloud condivisa per i piani Family e Premium. Scopri come gestire il nuovo pool da 2 TB, le date di transizione e i passaggi per mettere in sicurezza i propri file.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.