Vous ne souhaitez pas effectuer cette configuration manuellement ? Collez un lien vers cette page dans une session Devin et demandez-lui de tout configurer pour vous. Le workflow appelle l'[API v3](/fr/api-reference/v3/overview) 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](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) > **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](/fr/onboard-devin/environment) afin que Devin puisse le cloner, le construire et y pousser des modifications. 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](/fr/api-reference/v3/sessions/post-organizations-sessions) pour démarrer une session de correction : ```yaml theme={null} 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. 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. ``` ```txt Faire le suivi d'un test instable theme={null} L'échec de la CI était en fait dû à un test instable — il passe lors de la réexécution. Analysez le test dans src/__tests__/UserList.test.tsx et corrigez son instabilité. Vérifiez s'il s'agit d'un problème de timing, d'une race condition ou d'un nettoyage manquant entre les exécutions. ``` 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 : ```yaml theme={null} - 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à.

{title}