GitHub App

A cosa serve

La GitHub App fornisce all'API una capability server-to-server limitata per verificare main, il repository installato e il workflow Frontend approvato, poi effettuare dispatch e riconciliazione.

sequenceDiagram
    participant Admin
    participant API
    participant D1
    participant App as GitHub App
    participant Actions as GitHub Actions
    Admin->>API: azione deployment proiettata
    API->>D1: operation e attempt immutabili
    API->>App: JWT App e token installazione
    App-->>API: accesso repository-scoped
    API->>App: verifica main e workflow hardcoded
    API->>Actions: dispatch con input server-owned
    Actions-->>API: run autorevole o evidenza ambigua
    API->>D1: stato ed evidenza sanitizzata

Componenti che lo usano

Il provider GitHubAppFrontendDeploymentProvider, il servizio deployment Frontend, il workspace Admin e la riconciliazione di operation D1.

Dati e artefatti scambiati

L'API crea un JWT App breve, ottiene un token installazione, legge repository, ref main, workflow e run, e invia input di dispatch hardcoded. Conserva solo commit, run e stato sanitizzati.

Autenticazione e autorizzazione

La chiave privata autentica l'App verso GitHub; il token installazione limita la capability. L'autorizzazione utente resta nell'API e l'approvazione produzione richiede un umano. Il browser non riceve credenziali GitHub.

Cosa possiede il provider

GitHub possiede App, installation, token effimero, permessi repository, ref, workflow metadata, dispatch acknowledgement e run evidence.

Cosa possiede Architecture Coffee

L'API possiede repository unico atteso, workflow per ambiente, ref main, conferme, input, eligibility, approvazione e stato D1. Il chiamante non sceglie repository, workflow o ref.

Operazioni automatiche, manuali e protette

Capability e riconciliazione sono letture server-owned. Il dispatch avviene solo dopo richiesta autorizzata; in produzione segue l'approvazione umana separata. Creazione, rotazione e revoca chiavi sono operazioni security separate.

Fallimenti e comportamento fail-closed

Import chiave, firma JWT, token, scope installation, main, workflow o rete non autorevoli producono capability non disponibile. Dispatch ambiguo porta a unknown; non viene inventato un secondo run.

Verifiche operative

installation limitata al solo repository previsto;
main con SHA valido;
workflow hardcoded attivo;
produzione disabilitata salvo rollout esplicito;
un solo run compatibile in riconciliazione;
nessun token, JWT o chiave nei log.