Cosa sono le GitHub Actions e come usarle

Ogni progetto ha delle cose che vanno fatte a ogni modifica: lanciare i test, controllare lo stile del codice, mettere online la nuova versione. Farle a mano significa che prima o poi qualcuno se ne dimentica. Le GitHub Actions le fanno succedere da sole, direttamente nel repository. In questo articolo trovi come funzionano, il primo file da cui partire e le due cose da non sbagliare.

Cosa sono

Le GitHub Actions sono un sistema di automazione integrato in GitHub: esegui dei comandi su server messi a disposizione da GitHub, in risposta a eventi che accadono nel repository.

L'evento tipico è un invio di codice o l'apertura di una proposta di modifica. Ma può essere anche un orario prestabilito, o un avvio manuale.

È l'implementazione più diffusa del CI/CD — integrazione e distribuzione continue — con il vantaggio di stare già dentro il posto in cui il codice vive.

Come è fatto un workflow

I concetti sono quattro, dal più grande al più piccolo:

Workflow — un processo automatizzato, descritto in un file YAML dentro .github/workflows/.

Job — un blocco di lavoro che gira su una macchina propria. Più job dello stesso workflow girano in parallelo, salvo indicazione contraria.

Step — un singolo passaggio dentro un job.

Action — un componente riutilizzabile scritto da altri, che uno step può richiamare.

Un esempio minimo che lancia i test a ogni invio:

name: Test

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

Si legge dall'alto: si chiama "Test", parte a ogni push e a ogni pull request, gira su Linux, scarica il codice, prepara Node, installa le dipendenze, lancia i test.

uses richiama un'azione già pronta, run esegue un comando.

A cosa serve davvero

Gli usi più comuni, in ordine di quanto rendono:

Lanciare i test automaticamente. È il caso d'uso numero uno. Ogni proposta di modifica viene verificata prima che qualcuno la guardi, e chi revisiona sa già se funziona — vedi cos'è una pull request.

Controllare stile e formattazione. Linter e formattatore automatici eliminano un'intera categoria di discussioni nelle revisioni.

Costruire e distribuire. A ogni integrazione nel ramo principale, il sito o l'applicazione vanno online da soli.

Provare su più configurazioni. Lo stesso test su tre versioni di un linguaggio o su tre sistemi operativi, in parallelo.

Attività pianificate. Un controllo notturno, un report settimanale. È l'equivalente di un cron job, gestito da GitHub.

Automatismi sul repository. Etichettare le proposte, chiudere quelle inattive, avvisare qualcuno.

Quanto costa

Un punto pratico che sfugge spesso.

Sui repository pubblici l'uso è gratuito. Sui repository privati c'è un monte minuti mensile incluso, oltre il quale si paga a consumo.

Due cose da sapere sul conteggio:

I minuti si contano per job, non per workflow. Tre job in parallelo da 5 minuti consumano 15 minuti, non 5.

Le macchine non Linux costano di più. Windows e macOS hanno moltiplicatori sul consumo — macOS in particolare è nettamente più caro. Se non hai bisogno di quel sistema specifico, usa Linux.

Come si evita di bruciare minuti inutilmente:

• Metti in cache le dipendenze invece di reinstallarle a ogni esecuzione
• Limita quando parte il workflow: non serve rilanciare tutto se hai modificato solo il README
• Annulla le esecuzioni superate quando arriva un nuovo invio sullo stesso ramo

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

La sicurezza: due cose da non sbagliare

Questa è la parte che vale la pena leggere con attenzione, perché gli errori qui costano davvero.

I segreti non si scrivono nel file

Chiavi API, token, credenziali di distribuzione vanno nelle impostazioni del repository e richiamati così:

env:
  API_KEY: ${{ secrets.API_KEY }}

Mai scritti nel workflow. Il file è versionato: un segreto messo lì entra nella storia del repository e ci resta, anche se lo rimuovi in un commit successivo. A quel punto va considerato compromesso e sostituito, non solo cancellato.

Le azioni di terzi eseguono codice tuo

Ogni uses: qualcuno/qualcosa@v1 esegue codice scritto da altri, con accesso al tuo repository e ai segreti che gli passi.

Le precauzioni:

• Preferisci azioni ufficiali o di organizzazioni riconoscibili
• Fissa la versione. Meglio ancora, fissa l'identificatore esatto del commit invece dell'etichetta: un'etichetta può essere spostata, un commit no
• Dai i permessi minimi al workflow, esplicitamente

permissions:
  contents: read

C'è poi un punto specifico: i workflow innescati da proposte di modifica esterne vanno trattati con cautela, perché eseguono codice proposto da chi non conosci. GitHub ha delle protezioni predefinite, ma vale la pena non allentarle senza sapere cosa si sta facendo.

Il ragionamento generale sui componenti non affidabili è lo stesso di guardrail e sicurezza: il principio del privilegio minimo vale ovunque.

Errori comuni

Workflow troppo lenti. Se i test impiegano venti minuti, la gente smette di aspettarli. La cache delle dipendenze è quasi sempre il primo intervento risolutivo.

Test instabili. Un test che fallisce a caso una volta su cinque è peggio di nessun test: insegna al team a rilanciare senza guardare, e quando il fallimento è vero nessuno se ne accorge.

Far girare tutto su ogni modifica. Filtrare per percorso e per ramo riduce parecchio il consumo.

Nessuna notifica sui fallimenti. Un workflow che fallisce in silenzio è come non averlo.

Segreti passati a job che non ne hanno bisogno. Limita l'esposizione.

Le alternative

Vale la pena conoscerle:

GitLab CI/CD — integrato in GitLab, concettualmente molto simile, con un unico file di configurazione.

Servizi esterni (CircleCI, Travis, Buildkite) — indipendenti dalla piattaforma di hosting del codice, utili se lavori su più sistemi.

Esecuzione locale. Esistono strumenti per provare i workflow sul proprio computer prima di inviarli: risparmiano il ciclo "modifica, invia, aspetta, sbagliato, riprova" che altrimenti costa parecchio tempo.

Se il tuo codice è già su GitHub, le Actions sono la scelta di default sensata, semplicemente perché non aggiungono un servizio in più da collegare e gestire.

In sintesi

Le GitHub Actions eseguono automaticamente dei comandi in risposta a eventi del repository. La struttura è workflow → job → step, descritta in un file YAML dentro .github/workflows/.

Il caso d'uso da cui partire è uno: lanciare i test a ogni proposta di modifica. Da lì si aggiunge il resto — controlli di stile, costruzione, distribuzione automatica.

Sui costi, le due leve che contano: usa Linux (gli altri sistemi costano molto di più) e metti in cache le dipendenze.

E le due regole di sicurezza da non violare: i segreti nelle impostazioni, mai nel file — perché la storia del repository non si cancella — e azioni di terzi solo da fonti affidabili, con versione fissata e permessi minimi.

Se il concetto di integrazione continua ti è ancora poco chiaro, il quadro generale è in cos'è il CI/CD.