¿Prefieres no configurarlo manualmente? Pega un enlace a esta página en una sesión de Devin y pídele que lo configure todo por ti. El flujo de trabajo llama a la [API v3](/es/api-reference/v3/overview) de Devin para crear sesiones de forma programática. Crea un usuario de servicio y almacena su token como un secreto de GitHub Actions: 1. Ve a [app.devin.ai](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) > **Settings** > **Service Users** y crea un usuario de servicio con el permiso `ManageOrgSessions` 2. Copia el token de la API que se muestra después de crearlo — solo se muestra una vez 3. En tu repositorio de GitHub, ve a **Settings > Secrets and variables > Actions** 4. Añade dos secretos: `DEVIN_API_KEY` (el token) y `DEVIN_ORG_ID` (el ID de tu organización — obténlo llamando a `GET https://api.devin.ai/v3/enterprise/organizations` con tu token) Asegúrate de que el repositorio ya esté [configurado en la máquina de Devin](/es/onboard-devin/environment) para que Devin pueda clonarlo, compilarlo y hacer push en él. Crea `.github/workflows/devin-ci-fix.yml`. Este flujo de trabajo se ejecuta cada vez que el flujo de trabajo de CI existente finaliza con un error, extrae los nombres de los jobs que fallaron y llama a la [Devin API](/es/api-reference/v3/sessions/post-organizations-sessions) para iniciar una sesión de corrección: ```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.\" }" ``` Reemplaza `"CI"` en el array `workflows` por el valor exacto de `name:` de tu archivo de flujo de trabajo de CI existente (por ejemplo, `"Tests"`, `"Build & Test"`). Usa el campo `tags` en el cuerpo de la solicitud (por ejemplo, `"tags": ["ci-fix", "pr-312"]`) para llevar un registro de qué errores de CI ya han activado sesiones y evitar duplicados. Cuando falla la ejecución de CI de un PR, la Action extrae los detalles del error y se los pasa a Devin como mensaje de sesión. Este es un flujo típico de corrección automática: 1. **Lee los registros de CI** — Devin abre la URL de la ejecución y analiza la salida de errores, las trazas de pila y los resultados de pruebas de los jobs que fallaron 2. **Rastrea el error hasta el código** — Localiza el archivo y la línea relevantes en la rama del PR (por ejemplo, `UserList.tsx:34`) y lee el código que lo rodea y el diff reciente 3. **Publica una corrección** — Realiza un commit con un cambio específico directamente en la rama del PR, lo que vuelve a ejecutar la CI automáticamente 4. **Comenta en el PR** — Publica un resumen que explica la causa raíz y qué se cambió Ejemplo de comentario de PR 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 Dar seguimiento a una prueba inestable theme={null} La falla de CI en realidad fue una prueba inestable: pasa al reintentarla. Investiga la prueba en src/__tests__/UserList.test.tsx y corrige la inestabilidad. Verifica si es un problema de temporización, una condición de carrera o una falta de limpieza entre ejecuciones. ``` No todos los fallos de CI pueden solucionarse automáticamente: los timeouts en la infraestructura y los problemas de compilación de Docker no se resolverán con un cambio de código. Agrega una condición para que solo los fallos de trabajos relevantes activen a 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" \ ... ``` ### Mantén las correcciones fáciles de revisar Devin envía un commit de corrección, pero el PR aún requiere revisión humana antes de fusionarlo. Trata las correcciones automáticas como un punto de partida para el desarrollador, no como un reemplazo de la revisión de código. Si Devin no puede resolver el fallo, deja un comentario en el PR explicando lo que encontró para que un ingeniero pueda continuar a partir de ahí.

{title}