Skip to main content
1

Conserva la tua Devin API key su GitHub

Il workflow chiama la v3 API di Devin per creare sessioni in modo programmatico. Crea un service user e salva il relativo token come secret di GitHub Actions:
  1. Vai su app.devin.ai > Settings > Service Users e crea un service user con il permesso ManageOrgSessions
  2. Copia il token API mostrato dopo la creazione — viene visualizzato solo una volta
  3. Nel tuo repository GitHub, vai su Settings > Secrets and variables > Actions
  4. Aggiungi due secret: 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 di 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 non riusciti e chiama la Devin API 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 valore esatto di name: dal tuo file di workflow CI esistente (ad esempio, "Tests", "Build & Test").Usa il campo tags nel corpo della richiesta (ad esempio, "tags": ["ci-fix", "pr-312"]) per tenere traccia di quali errori della CI hanno già attivato sessioni ed evitare duplicati.
3

Cosa accade quando la CI fallisce

Quando l’esecuzione 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 di errore, gli stack trace e i risultati dei test dei job non riusciti
  2. Rintraccia l’errore nel codice — Individua il file e la riga rilevanti sul branch della PR (ad es. UserList.tsx:34) e legge il codice circostante e la diff recente
  3. Invia una correzione — Esegue il commit di una modifica mirata direttamente sul branch della PR, che riavvia 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ì.