Git 25
🔀 Git & GitHub · Modulo 5 · Lezione 25
Introduzione a GitHub Actions ⚡
Cos’è la CI/CD · Workflow automatici · Il tuo primo Action · Trigger, job e step
⚡ Finora hai fatto tutto manualmente: test, build, deploy. Da questa lezione, GitHub fa il lavoro per te. GitHub Actions è un sistema di automazione integrato nel repository: ogni volta che succede qualcosa (push, PR, merge), GitHub esegue automaticamente i comandi che definisci — test, linting, build, deploy, notifiche. È la CI/CD (Continuous Integration / Continuous Delivery) senza uscire da GitHub.
🎯 Obiettivi della lezione
- Capire cos’è la CI/CD e perché è importante
- Conoscere i concetti base di GitHub Actions: workflow, trigger, job, step
- Creare il tuo primo workflow che si attiva a ogni push
- Leggere i log di esecuzione su GitHub
- Capire la struttura di un file YAML di workflow
- Conoscere il marketplace delle Actions
📖 1. Teoria
1.1 — Cos’è la CI/CD
2. “Funziona sul mio computer!” ✅
3. Merge in main
4. Il sito si rompe in produzione 💥
5. “Chi ha rotto main?!” 🔥
6. 2 ore per trovare il bug
2. GitHub Actions esegue i test automaticamente
3. ❌ Test fallito! La PR mostra il problema
4. Marco corregge prima del merge
5. ✅ Test passati → merge sicuro
6. Main è sempre funzionante
1.2 — I concetti base di GitHub Actions
| Concetto | Cos’è | Analogia |
|---|---|---|
| Workflow | Un file YAML che definisce un’automazione completa | La “ricetta” — l’intero piano dall’inizio alla fine |
| Trigger (on) | L’evento che fa partire il workflow (push, PR, schedule…) | L'”interruttore” — quando si accende l’automazione |
| Job | Un gruppo di step che eseguono su una macchina virtuale | Un “reparto” della fabbrica — una macchina dedicata |
| Step | Un singolo comando o azione all’interno di un job | Un “passo” della ricetta — un’operazione singola |
| Action | Un componente riusabile creato dalla community (es. actions/checkout) |
Un “attrezzo” prefabbricato — non devi costruirlo tu |
| Runner | La macchina virtuale che esegue il job (fornita gratis da GitHub) | Il “computer in cloud” che fa il lavoro al posto tuo |
1.3 — Dove vivono i workflow
I workflow sono file YAML nella cartella .github/workflows/ del repository. Puoi avere quanti workflow vuoi — ogni file .yml è un’automazione indipendente.
├── 📁 ISSUE_TEMPLATE/ (lezione 24)
├── PULL_REQUEST_TEMPLATE.md (lezione 24)
└── 📁 workflows/ ← NUOVO! I tuoi workflow vanno qui
├── ci.yml ← test automatici a ogni push
├── deploy.yml ← deploy automatico dopo merge
└── lint.yml ← controllo stile del codice
1.4 — Anatomia di un workflow YAML
name: CI ← nome che appare nella tab Actions
on: ← TRIGGER: quando si attiva
push:
branches: [main] ← solo push su main
pull_request:
branches: [main] ← o PR verso main
jobs: ← JOB: cosa fare
test: ← nome del job
runs-on: ubuntu-latest ← la macchina virtuale (runner)
steps: ← STEP: i passi del job
– name: Checkout codice
uses: actions/checkout@v4 ← action della community
– name: Mostra i file
run: ls -la ← comando shell
– name: Verifica che index.html esiste
run: test -f index.html ← se il file non esiste, il job fallisce
| Chiave | Cosa significa |
|---|---|
| name | Il nome del workflow — appare nella tab Actions di GitHub |
| on | Il trigger: quale evento fa partire il workflow (push, pull_request, schedule…) |
| jobs | La lista dei job da eseguire. Ogni job ha un nome (es. test) e gira su una macchina separata |
| runs-on | Il sistema operativo del runner: ubuntu-latest, windows-latest, macos-latest |
| steps | I passi del job, eseguiti in ordine. Ogni step ha un name e un run (comando) o uses (action) |
| uses | Usa un’action predefinita (es. actions/checkout@v4 scarica il codice del repo nel runner) |
| run | Esegue un comando shell (es. npm test, python -m pytest, ls -la) |
1.5 — I trigger più comuni
| Trigger | Quando si attiva | Caso d’uso |
|---|---|---|
| push | A ogni push sul branch specificato | Test e build dopo il merge |
| pull_request | Quando una PR viene aperta, aggiornata o riaperta | Test prima del merge — il risultato appare nella PR |
| schedule | A orari prestabiliti (cron syntax) | Backup giornaliero, report settimanale |
| workflow_dispatch | Manualmente, con un click dalla tab Actions | Deploy manuale, task una tantum |
| release | Quando viene pubblicata una nuova release | Build e distribuzione dei pacchetti |
1.6 — actions/checkout: l’action che userai sempre
Il runner (la macchina virtuale di GitHub) parte vuoto — non ha il tuo codice. Il primo step di quasi ogni workflow è actions/checkout@v4, che scarica il codice del repository nel runner. Senza questo step, i comandi successivi non trovano nessun file.
steps:
– name: Checkout codice
uses: actions/checkout@v4 ← scarica il repo nel runner
# Da questo punto in poi, i tuoi file sono disponibili
– name: Verifica
run: ls -la ← ora vede index.html, style.css, ecc.
1.7 — Leggere i risultati: la tab Actions
Dopo il push, il workflow si attiva automaticamente. Puoi seguirne l’esecuzione nella tab “Actions” del repository.
📌 I risultati appaiono anche nelle PR! Se il workflow si attiva su pull_request, il risultato (✅ o ❌) appare direttamente nella pagina della PR, nella sezione “Checks”. Combinato con le branch protection rules (Lezione 20), puoi bloccare il merge se i test falliscono — il pulsante Merge resta grigio finché tutti i check non sono verdi.
1.8 — Il Marketplace delle Actions
Non devi scrivere tutto da zero — la community ha creato migliaia di actions riusabili. Il GitHub Marketplace è il catalogo dove trovarle. Le usi con uses: autore/nome-action@versione.
| Action | Cosa fa | Uso |
|---|---|---|
| actions/checkout@v4 | Scarica il codice del repo nel runner | Sempre — primo step di ogni workflow |
| actions/setup-node@v4 | Installa Node.js (versione a scelta) | Progetti JavaScript/TypeScript |
| actions/setup-python@v5 | Installa Python (versione a scelta) | Progetti Python |
| actions/upload-artifact@v4 | Salva file prodotti dal workflow (report, build) | Salvare output scaricabili |
💻 2. Esempi guidati
Esempio A — Il tuo primo workflow: “Hello GitHub Actions”
$ mkdir -p .github/workflows
# Crea il workflow
$ cat > .github/workflows/hello.yml <<‘EOF’
name: Hello Actions
on:
push:
branches: [main]
jobs:
saluta:
runs-on: ubuntu-latest
steps:
– name: Saluto
run: echo “Ciao! GitHub Actions funziona! 🎉”
– name: Data e ora
run: date
– name: Info sistema
run: uname -a
EOF
$ git add .github/workflows/hello.yml
$ git commit -m “Aggiunto primo workflow GitHub Actions”
$ git push
# Vai su GitHub → tab Actions → vedi “Hello Actions” in esecuzione!
Esempio B — Workflow CI per un progetto web
name: CI — Verifica progetto web
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
verifica:
runs-on: ubuntu-latest
steps:
– name: Checkout codice
uses: actions/checkout@v4
– name: Verifica che i file essenziali esistono
run: |
echo “Verifico file essenziali…”
test -f index.html || (echo “❌ index.html mancante!” && exit 1)
test -f style.css || (echo “❌ style.css mancante!” && exit 1)
test -f README.md || (echo “❌ README.md mancante!” && exit 1)
echo “✅ Tutti i file essenziali presenti!”
– name: Verifica HTML valido (base)
run: |
echo “Verifico tag HTML…”
grep -q “<html” index.html || (echo “❌ Tag html mancante!” && exit 1)
grep -q “</html>” index.html || (echo “❌ Tag html non chiuso!” && exit 1)
echo “✅ Struttura HTML base OK!”
– name: Conta le righe del progetto
run: |
echo “📊 Statistiche del progetto:”
echo “HTML: $(find . -name ‘*.html’ | xargs wc -l | tail -1) righe”
echo “CSS: $(find . -name ‘*.css’ | xargs wc -l | tail -1) righe”
echo “JS: $(find . -name ‘*.js’ | xargs wc -l | tail -1) righe”
📌 Il pipe | dopo run: permette di scrivere comandi su più righe. Senza il pipe, puoi scrivere un solo comando per run:. Con il pipe, scrivi un intero script bash. Il exit 1 fa fallire lo step (e quindi il job) — è il modo per segnalare un errore.
Esempio C — Workflow con attivazione manuale
name: Report progetto
on:
workflow_dispatch: ← attivazione manuale!
jobs:
report:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– name: Genera report
run: |
echo “📋 Report del progetto — $(date)”
echo “File: $(find . -type f | wc -l)”
echo “Commit: $(git log –oneline | wc -l)”
echo “Branch: $(git branch -r | wc -l)”
echo “Ultimo commit: $(git log -1 –format=’%s (%an, %ar)’)”
workflow_dispatch aggiunge un pulsante “Run workflow” nella tab Actions. Utile per task che non devono partire automaticamente ma solo quando li avvii tu.🏋️ 3. Esercizi
🟢 Esercizio 1 — Il tuo primo workflow (Facile)
.github/workflows/hello.yml.b) Committa e pusha.
c) Vai sulla tab Actions di GitHub. Vedi il workflow “Hello Actions” in esecuzione?
d) Clicca sul workflow → clicca sul job “saluta” → leggi i log di ogni step.
e) Il pallino è verde (✅)? Il messaggio “Ciao!” appare nei log?
🔵 Esercizio 2 — CI per progetto web (Medio)
.github/workflows/ci.yml usando l’Esempio B.b) Committa e pusha. Il workflow parte?
c) Se il tuo repository ha
index.html, style.css e README.md, il workflow dovrebbe passare (verde).d) Ora rinomina temporaneamente
style.css in styles.css, committa e pusha. Il workflow fallisce (rosso)?e) Leggi i log: quale step è fallito? Cosa dice il messaggio di errore?
f) Correggi (rinomina indietro), committa e pusha. Torna verde?
🟠 Esercizio 3 — CI sulla Pull Request (Medio)
pull_request.b) Crea un branch, fai una modifica, pusha, apri una PR.
c) Nella pagina della PR, scorri fino alla sezione “Checks”. Il workflow CI è in esecuzione?
d) Se passa, vedi il pallino verde ✅. Se fallisce, vedi il rosso ❌.
e) Se hai le branch protection rules attive (Lezione 20), configura “Require status checks to pass” e seleziona il tuo workflow CI. Ora il merge è bloccato se i test falliscono!
🟣 Esercizio 4 — Scrivi un workflow personalizzato (Difficile)
check.yml che verifica il tuo progetto con almeno 5 controlli:a) Verifica che i file essenziali esistano (personalizzali per il tuo progetto).
b) Verifica che il README contenga il nome del progetto (usa
grep).c) Verifica che non ci siano file
.env nel repository (sicurezza!).d) Conta i file per tipo (HTML, CSS, JS) e stampa un riepilogo.
e) Verifica che il file
.gitignore esista e contenga node_modules.f) Il workflow deve attivarsi sia su push che su pull_request verso main.
g) Committa, pusha, verifica che funzioni. Poi fai fallire intenzionalmente un controllo e verifica che il workflow diventi rosso.
❓ 4. Quiz di verifica
1. Cos’è la CI/CD e perché è utile?
Mostra risposta
CI (Continuous Integration) = il codice viene automaticamente testato a ogni push o PR. Se i test falliscono, il team lo sa subito — il bug viene corretto prima del merge. CD (Continuous Delivery/Deployment) = dopo il merge, il codice viene automaticamente distribuito (pubblicato su un sito, rilasciato come app). Insieme eliminano i processi manuali e garantiscono che main sia sempre funzionante e aggiornato. Senza CI/CD, i bug si accumulano e vengono scoperti troppo tardi; con CI/CD, ogni modifica è verificata immediatamente.
2. Qual è la differenza tra un “job” e uno “step” in GitHub Actions?
Mostra risposta
Un job è un gruppo di step che gira su una macchina virtuale dedicata (runner). Un step è un singolo comando o azione all’interno del job. I job possono girare in parallelo (ciascuno sul proprio runner) o in sequenza. Gli step di un job girano sempre in sequenza sullo stesso runner. Un workflow può avere più job (es. un job per i test, uno per il build); ogni job ha più step (es. checkout, installazione, test).
3. A cosa serve actions/checkout@v4 e perché è quasi sempre il primo step?
Mostra risposta
Scarica il codice del repository nel runner (la macchina virtuale). Il runner parte vuoto — non ha nessun file del tuo progetto. Senza actions/checkout, i comandi successivi (come npm test o test -f index.html) non troverebbero nessun file e fallirebbero. È il primo step perché tutti gli step successivi hanno bisogno dei file del progetto. L’unica eccezione sono step che non toccano il codice (es. inviare una notifica).
4. Qual è la differenza tra uses e run in uno step?
Mostra risposta
uses esegue un’action predefinita creata dalla community o da GitHub — un componente riusabile con nome e versione (es. actions/checkout@v4). run esegue un comando shell diretto — qualsiasi comando che scriveresti nel terminale (es. npm test, ls -la, echo "hello"). In uno step usi o uses o run, mai entrambi. La scelta dipende da cosa devi fare: se esiste un’action per quel compito, usa uses; altrimenti scrivi il comando con run.
5. In quale cartella devono stare i file dei workflow?
Mostra risposta
In .github/workflows/ alla radice del repository. Ogni file .yml in questa cartella è un workflow indipendente. Il nome del file non conta (puoi chiamarlo ci.yml, test.yml, deploy.yml — quello che preferisci). Il nome visualizzato nella tab Actions è quello specificato dalla chiave name: nel file YAML, non il nome del file. Puoi avere quanti workflow vuoi — ogni file è un’automazione separata con i propri trigger e job.
6. Il workflow fallisce. Come trovi il problema?
Mostra risposta
Vai nella tab Actions di GitHub → clicca sul workflow fallito (pallino rosso) → clicca sul job fallito → si aprono i log di ogni step. Lo step fallito ha un’icona rossa — espandilo per vedere l’output del comando e il messaggio di errore. L’errore ti dice cosa è andato storto: file mancante, test fallito, comando non trovato. Correggi il problema in locale, committa, pusha — il workflow riparte automaticamente. Nelle PR, il risultato aggiornato appare nella sezione “Checks”.
📚 Riepilogo della lezione
- CI = test automatici a ogni push. CD = deploy automatico dopo il merge.
- Workflow = file YAML in
.github/workflows/ - Struttura: name → on (trigger) → jobs → steps
- Trigger comuni:
push,pull_request,workflow_dispatch(manuale) uses= action predefinita ·run= comando shellactions/checkout@v4= primo step di ogni workflow (scarica il codice nel runner)- Risultati nella tab Actions e nella sezione Checks delle PR
run: |per comandi multi-riga ·exit 1per far fallire- Il Marketplace ha migliaia di actions pronte all’uso
Prossima lezione →
Lezione 26 — Workflow YAML
Approfondimento sulla sintassi YAML. Job multipli e dipendenze.
Variabili d’ambiente. Matrici di test. Condizioni (if).
Corso Git & GitHub · Per studenti e insegnanti · Lezione 25 di 45