Skip to main content

Correction automatique des builds CI en échec

Ajoutez une GitHub Action qui appelle Devin pour corriger les builds CI en échec sur vos PR.
AuthorCognition
CategoryAutomatisations
FeaturesAPI
1

Enregistrez votre Devin API key dans GitHub

Le workflow appelle l’API v3 de Devin pour créer des sessions de manière programmatique. Créez un utilisateur de service et enregistrez son jeton comme secret GitHub Actions :
  1. Allez sur app.devin.ai > Settings > Service Users et créez un utilisateur de service avec l’autorisation ManageOrgSessions
  2. Copiez le jeton d’API affiché après la création — il n’est affiché qu’une seule fois
  3. Dans votre dépôt GitHub, accédez à Settings > Secrets and variables > Actions
  4. Ajoutez deux secrets : DEVIN_API_KEY (le jeton) et DEVIN_ORG_ID (l’ID de votre organisation — obtenez-le en appelant GET https://api.devin.ai/v3/enterprise/organizations avec votre jeton)
Assurez-vous que le dépôt est déjà configuré dans Devin’s Machine afin que Devin puisse le cloner, le construire et y pousser des modifications.
2

Ajouter le fichier de workflow

Créez .github/workflows/devin-ci-fix.yml. Ce workflow se déclenche chaque fois que votre workflow CI existant se termine en échec, extrait les noms des jobs en échec et appelle la Devin API pour démarrer une session de correction :
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.\"
            }"
Remplacez "CI" dans le tableau workflows par la valeur exacte de name: de votre fichier de workflow CI existant (par exemple, "Tests", "Build & Test").Utilisez le champ tags dans le corps de la requête (par exemple, "tags": ["ci-fix", "pr-312"]) pour suivre quels échecs CI ont déjà déclenché des sessions et éviter les doublons.
3

Que se passe-t-il en cas d’échec de l’intégration continue ?

Lorsqu’une exécution CI d’une PR échoue, l’Action extrait les détails de l’échec et les transmet à Devin comme invite de session. Voici un flux de correction automatique typique :
  1. Lit les logs de la CI — Devin ouvre l’URL de l’exécution et analyse la sortie d’erreur, les stack traces et les résultats de test des jobs en échec
  2. Fait le lien entre l’erreur et le code — Localise le fichier et la ligne concernés sur la branche de la PR (par exemple UserList.tsx:34) et lit le code environnant ainsi que le diff récent
  3. Pousse un correctif — Fait un commit ciblé directement sur la branche de la PR, ce qui relance automatiquement la CI
  4. Ajoute un commentaire sur la PR — Publie un récapitulatif expliquant la cause profonde et ce qui a été modifié
Exemple de commentaire de PR de la part de 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

Limitez-la aux erreurs pertinentes

Tous les échecs de CI ne se prêtent pas à une correction automatique : les timeouts d’infrastructure et les problèmes de build Docker ne seront pas résolus par une modification du code. Ajoutez une condition pour que seuls les échecs de jobs pertinents déclenchent 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" \
          ...

Veiller à ce que les correctifs restent faciles à relire

Devin pousse un commit de correction, mais la PR nécessite toujours une revue humaine avant la fusion. Considérez les corrections automatiques comme un point de départ pour le développeur, pas comme un remplacement de la revue de code. Si Devin ne parvient pas à résoudre le problème, il ajoute un commentaire sur la PR en expliquant ce qu’il a trouvé afin qu’un ingénieur puisse reprendre à partir de là.