Skip to main content
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:
name: Auto-fix CI with Devin

on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

jobs:
  trigger-devin-fix:
    if: >
      github.event.workflow_run.conclusion == 'failure' &&
      github.event.workflow_run.pull_requests[0]
    runs-on: ubuntu-latest
    steps:
      - name: Get failure details
        id: failure
        uses: actions/github-script@v7
        with:
          script: |
            const run = context.payload.workflow_run;
            const pr = run.pull_requests[0];
            const jobs = await github.rest.actions.listJobsForWorkflowRun({
              owner: context.repo.owner,
              repo: context.repo.repo,
              run_id: run.id
            });
            const failed = jobs.data.jobs
              .filter(j => j.conclusion === 'failure')
              .map(j => j.name);
            core.setOutput('pr_number', pr.number);
            core.setOutput('branch', pr.head.ref);
            core.setOutput('failed_jobs', failed.join(', '));
            core.setOutput('run_url', run.html_url);

      - name: Trigger Devin session
        run: |
          curl -s -X POST "https://api.devin.ai/v3/organizations/${{ secrets.DEVIN_ORG_ID }}/sessions" \
            -H "Authorization: Bearer ${{ secrets.DEVIN_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d "{
              \"prompt\": \"CI failed on PR #${{ steps.failure.outputs.pr_number }} in ${{ github.repository }}. Failed jobs: ${{ steps.failure.outputs.failed_jobs }}. Run: ${{ steps.failure.outputs.run_url }}. Branch: ${{ steps.failure.outputs.branch }}. Read the CI logs, identify the root cause, and push a fix to the branch.\"
            }"
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:
CI failure in test-unit — fixed

Root cause: `UserList.tsx:34` calls `.map()` on `props.users`, which is
undefined when the API returns an empty response body instead of `[]`.

Fix: Added a fallback — `const users = props.users ?? [];`
Added a test case for the empty-response scenario.
All 312 tests passing.
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:
      - name: Trigger Devin session
        if: >
          contains(steps.failure.outputs.failed_jobs, 'test') ||
          contains(steps.failure.outputs.failed_jobs, 'lint') ||
          contains(steps.failure.outputs.failed_jobs, 'typecheck')
        run: |
          curl -s -X POST "https://api.devin.ai/v3/organizations/${{ secrets.DEVIN_ORG_ID }}/sessions" \
          ...

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ì.