Skip to main content
Non vuoi configurare tutto manualmente? Incolla un collegamento a questa pagina in una sessione di Devin e chiedigli di configurare tutto per te.
1

Salva la tua chiave API di Devin in GitHub

Il workflow chiama le API v3 di Devin per creare sessioni in modo programmatico. Crea un utente di servizio e salva il suo token come segreto di GitHub Actions:
  1. Vai su app.devin.ai > Settings > Service Users e crea un utente di servizio con il permesso ManageOrgSessions
  2. Copia il token API mostrato dopo la creazione — viene visualizzato una sola volta
  3. Nel tuo repository GitHub, vai su Settings > Secrets and variables > Actions
  4. Aggiungi due segreti: DEVIN_API_KEY (il token) e DEVIN_ORG_ID (l’ID della tua organizzazione — ottienilo chiamando GET https://api.devin.ai/v3/enterprise/organizations con il tuo token)
Assicurati che il repository sia già configurato sulla Machine di Devin così che Devin possa clonarlo, compilarlo e fare push.
2

Aggiungi il file del workflow

Crea .github/workflows/devin-ci-fix.yml. Questo workflow si attiva ogni volta che il tuo workflow CI esistente termina con un errore, estrae i nomi dei job falliti e chiama le API di Devin per avviare una sessione di correzione:
Sostituisci "CI" nell’array workflows con il name: esatto del tuo file di workflow CI esistente (es. "Tests", "Build & Test").Usa il campo tags nel corpo della richiesta (es. "tags": ["ci-fix", "pr-312"]) per tenere traccia di quali errori CI hanno già avviato sessioni ed evitare duplicati.
3

Cosa succede quando la CI fallisce

Quando la CI di una PR fallisce, l’Action estrae i dettagli dell’errore e li passa a Devin come prompt di sessione. Ecco un tipico flusso di correzione automatica:
  1. Legge i log della CI — Devin apre l’URL dell’esecuzione e analizza l’output degli errori, gli stack trace e i risultati dei test dai job falliti
  2. Risale all’errore nel codice — Individua il file e la riga rilevanti nel branch della PR (es. UserList.tsx:34) e legge il codice circostante e il diff recente
  3. Fa push di una correzione — Esegue il commit di una modifica mirata direttamente nel branch della PR, che ri-attiva automaticamente la CI
  4. Commenta sulla PR — Pubblica un riepilogo che spiega la causa principale e cosa è stato modificato
Esempio di commento sulla PR da parte di Devin:
4

Limita l'ambito agli errori corretti

Non tutti gli errori in CI traggono beneficio da una correzione automatica: i timeout dell’infrastruttura e i problemi di build Docker non verranno risolti da una modifica al codice. Aggiungi una condizione in modo che solo gli errori dei job rilevanti attivino Devin:

Mantieni le correzioni facili da rivedere

Devin esegue un commit di correzione, ma la PR richiede comunque una revisione umana prima del merge. Considera le correzioni automatiche come un punto di partenza per lo sviluppatore, non come un sostituto della revisione del codice. Se Devin non riesce a risolvere il problema, aggiunge un commento alla PR spiegando cosa ha trovato, così un ingegnere può riprendere il lavoro da lì.