Istruzione pronta · Ridurre il consumo dei minuti GitHub Actions (CI)

Creato 2026-06-06 (sessione BOS · Gregorio). Da eseguire in una sessione Claude nel repo del codice D:\Desktop\Multiverbe (NON in questo repo strategia). Dettaglio della decisione: execution/decisions-log.md v82. Action item collegato: github-actions-ci-minutes-optimize-2026-06-06 in source/_meta/status.json.

Perché (in parole semplici)

GitHub Actions è il sistema che, a ogni modifica caricata sul repo del codice, lancia automaticamente i controlli (verifica del codice, costruzione, test, scansioni di sicurezza). Il piano include 3.000 minuti al mese. Con la nuova capacità di lavoro 4x (molte sessioni in parallelo, molti caricamenti) ne abbiamo bruciati il 90% in 5 giorni (email GitHub del 2026-06-05). Passare a un piano a pagamento da solo non aumenta i minuti inclusi: la cura vera è far lavorare i controlli in modo più intelligente, non di più.

Prompt da incollare nella prossima sessione sul repo del codice

Obiettivo: ridurre il consumo dei minuti GitHub Actions senza perdere qualità dei controlli.
Lavoriamo nel repo del codice (questo), cartella .github/workflows.

Fai una sessione mirata:
1. Inventario: elenca tutti i workflow in .github/workflows e, per ciascuno,
   dimmi quando parte (push? pull_request? su quali branch?), quanto dura in media,
   e quanti minuti ha consumato di recente. Identifica i più pesanti
   (es. Frontend CI, Schema Drift Check, Semgrep, Trivy).
2. Concurrency con cancel-in-progress: aggiungi a ogni workflow un gruppo di
   concorrenza per ramo, così che a ogni nuovo caricamento i controlli del run
   precedente ancora in corso vengano annullati (niente run vecchi che girano a vuoto).
3. Path filter: fai partire ogni workflow solo quando cambiano davvero i file che
   gli competono (es. la scansione del frontend solo se cambia il frontend),
   con paths/paths-ignore. Non lanciare tutto a ogni modifica.
4. Caching: assicurati che dipendenze e build usino la cache (setup-node cache,
   cache di pnpm/npm, cache di build) per accorciare ogni run.
5. Snellisci i ridondanti: se due workflow fanno lo stesso lavoro o girano sia su
   push sia su PR per lo stesso commit, unificali o limita i trigger.
6. Sicurezza invariata: NON indebolire le scansioni di sicurezza (Semgrep/Trivy/
   secret scanning). Falle girare in modo mirato (path filter + concurrency),
   non meno accuratamente.

Vincoli:
- Una sola PR pulita, CI verde, niente comportamento dell'app modificato.
- Misura prima/dopo: stima quanti minuti si risparmiano per ciclo tipico.
- Aggiorna il BOS (decisions-log + chiudi l'action item
  github-actions-ci-minutes-optimize-2026-06-06) quando è fatto e verificato.

Rete di sicurezza opzionale (lato founder, 2 minuti)

Nelle impostazioni di fatturazione dell'organizzazione metaverbe-hub (GitHub → Settings → Billing → Budgets and alerts) si può impostare un avviso o un limite di spesa per Actions, così non ci sono sorprese oltre i 3.000 minuti inclusi. Un budget a 0 bloccherebbe del tutto i controlli fino al reset (1° luglio 2026): da usare solo se si vuole fermare tutto, non come impostazione normale.

Buona abitudine permanente

Sessioni di codice: lavorare a blocchi e fare un solo caricamento (push) quando è pronto e testato, invece di tanti piccoli. Meno push = meno minuti.
Sessioni di strategia/BOS: "aggiorna BOS" è economico (la pubblicazione la fa Vercel, non consuma i minuti GitHub).