Che cosa automatizza davvero GitHub Actions
GitHub Actions è la piattaforma di automazione integrata nel repository: esegue processi automatizzati quando accade qualcosa nel repository. Il punto da fissare subito è che “qualcosa” non significa soltanto un push di codice da compilare.
CI/CD resta il caso d’uso più noto — la continuous integration che costruisce e verifica ogni modifica, il continuous deployment che la porta in un ambiente — ma la stessa piattaforma reagisce all’apertura di una issue, a un commento, alla pubblicazione di una release, all’aggiunta di una label, a una nuova discussion. L’esempio canonico della documentazione non è una build: è un workflow che applica automaticamente le label giuste quando qualcuno apre una issue. Da lì si automatizza tutto il resto: assegnare un revisore, accogliere chi contribuisce per la prima volta, aggiornare un project, pubblicare un pacchetto, notificare un canale esterno. Due trigger, poi, non dipendono da alcun evento umano: schedule, che fa partire il workflow a orari definiti con sintassi cron, e workflow_dispatch, che aggiunge l’avvio manuale da interfaccia, API o CLI con parametri di input.
Workflow, evento, job, action e runner
Un workflow è un processo automatizzato configurabile che esegue uno o più job. Vive in un file YAML nella cartella .github/workflows del repository, e un repository può averne diversi, ciascuno con un compito differente.
Un event è un’attività specifica del repository che avvia un’esecuzione del workflow; si dichiara con la chiave on, e quando l’evento si verifica GitHub cerca i workflow che lo dichiarano e li fa partire.
Un job è un insieme di step eseguiti sullo stesso runner. I job partono in parallelo, a meno che non si dichiari una dipendenza con needs, che li mette in sequenza. Un singolo step può essere un comando di shell (run) oppure l’invocazione di un’action (uses).
Un’action è un blocco di codice riutilizzabile e già pronto che svolge un compito preciso, così da non riscrivere ogni volta la stessa logica nel file di workflow.
Un runner è il server che esegue il workflow, e ogni runner esegue un job alla volta.
Occhio alla confusione più frequente, che l’esame sfrutta volentieri nelle domande a scelta multipla: “GitHub Actions” è la piattaforma, un “workflow” è il file che descrive l’automazione, un’“action” è il singolo mattoncino riutilizzabile richiamato da uno step. Non sono sinonimi.
Runner ospitati da GitHub o self-hosted
I GitHub-hosted runner sono macchine virtuali fornite e mantenute da GitHub, con sistema operativo Ubuntu Linux, Windows o macOS. Ogni job riceve una VM nuova, già equipaggiata con l’applicazione runner e altri strumenti preinstallati: manutenzione e aggiornamenti non sono a tuo carico. Il runner si sceglie con la chiave runs-on.
I self-hosted runner sono macchine tue, registrate su GitHub a livello di repository, di organization o di enterprise. Li scegli quando ti servono hardware particolare, un sistema operativo non offerto, software proprietario già installato o l’accesso a risorse della rete interna. In cambio la manutenzione è tua: l’applicazione runner si aggiorna da sola, ma il sistema operativo e tutto il resto del software li aggiorni tu.
Il principio di consumo, da ricordare senza memorizzare cifre: i runner standard ospitati da GitHub sono gratuiti nei repository pubblici e i self-hosted runner lo sono sempre; nei repository privati si consumano i minuti e lo spazio di archiviazione inclusi nel piano dell’account.
Marketplace, riuso e che cosa chiede l’esame
Non serve scrivere tutto da zero. GitHub Marketplace raccoglie le action pubblicate dalla community e da GitHub stessa: le sfogli dall’editor di workflow del repository e le richiami indicando proprietario, repository e un riferimento di versione. Un badge di verifica segnala che GitHub ha verificato il creatore come organizzazione partner; per affidabilità la documentazione consiglia di agganciare l’action al SHA del commit, immutabile a differenza di un tag o di un branch.
Puoi anche scriverne di tue — di tipo Docker container, JavaScript o composite, quest’ultima per raggruppare più step in una sola action — descritte da un file di metadati action.yml; per condividerle con tutti, il repository deve essere pubblico. Per partire in fretta GitHub propone dei workflow template già pronti per CI, deploy, automazione, code scanning e Pages, suggeriti in base al codice che trova nel repository. I risultati di ogni esecuzione, job per job e step per step, si leggono nella tab Actions.
Su questo obiettivo l’esame verifica che tu sappia descrivere scopo e capacità di GitHub Actions: riconoscere i componenti e il loro ruolo, sapere che i workflow sono file YAML dentro .github/workflows, e soprattutto non cadere nell’equazione “Actions uguale CI/CD”. Se una domanda chiede quale strumento GitHub usare per etichettare automaticamente le issue o per avvisare un team quando esce una release, la risposta è GitHub Actions.