GitHub Actions ed Environments

A cosa serve

ci.yml valida test, tipi, build, dry-run, documentazione e artefatti generati; non riceve segreti o Environment di produzione e non muta risorse remote.

Componenti che lo usano

Pull request, main e operatori autorizzati.

Dati e artefatti scambiati

Commit, metadata PR, log sanitizzati e artefatti di validazione.

Autenticazione e autorizzazione

CI è read-only; gli Environment proteggono le operazioni manuali.

Cosa possiede il provider

GitHub possiede esecuzioni, approvazioni Environment e log.

Cosa possiede Architecture Coffee

Il repository possiede workflow, conferme e contratti di validazione.

Operazioni automatiche, manuali e protette

development-release.yml promuove l'exact SHA di CI in Development; production-release.yml promuove soltanto un tag canonico eleggibile. Il job Production riceve le credenziali Cloudflare e il solo mode email non-secret dall'Environment protetto, lo valida prima di qualsiasi migration/upload e usa upload/deploy di versioni senza distribuire trigger. I workflow operations manuali espongono soltanto preflight non mutanti. Nessun gate chiama Mailjet e nessun workflow di deploy web è attivo.

Fallimenti e comportamento fail-closed

Input, branch, tag, Environment, provenienza Worker o mode email errati impediscono il job. Un mode protetto assente/invalido termina prima di D1 o upload; un upload/deploy ambiguo viene riletto e non ritentato.

Verifiche operative

Leggere check CI e l'evidenza Issue-native senza dedurre autorizzazione.

Riferimenti canonici

.github/workflows/, AGENTS.md e docs/operating-guide.md.

La selezione backend resta nelle Issue native e nel Project #1; il frontend usa Project #2. Project #3 è archiviato. Status pianifica il lavoro e non viene interrogato da CI, build o deploy. Un workflow riuscito non sostituisce la review e il merge Fra dell'Issue: il merge è il gate umano, il workflow è un meccanismo tecnico entro quello scope.