Skip to main content
不想手动配置?将本页链接粘贴到 Devin session 中,让它为你完成所有设置。
1

Store your Devin API key in GitHub

The workflow calls Devin’s v3 API to create sessions programmatically. Create a service user and store its token as a GitHub Actions secret:
  1. Go to app.devin.ai > Settings > Service Users and create a service user with ManageOrgSessions permission
  2. Copy the API token shown after creation — it’s only displayed once
  3. In your GitHub repo, navigate to Settings > Secrets and variables > Actions
  4. Add two secrets: DEVIN_API_KEY (the token) and DEVIN_ORG_ID (your organization ID — get it by calling GET https://api.devin.ai/v3/enterprise/organizations with your token)
请确保该代码仓库已在 Devin 的 Machine 上完成配置,以便 Devin 可以克隆、构建并向其推送代码。
2

Add the workflow file

Create .github/workflows/devin-ci-fix.yml. This workflow fires whenever your existing CI workflow completes with a failure, extracts the failing job names, and calls the Devin API to start a fix session:
Replace "CI" in the workflows array with the exact name: from your existing CI workflow file (e.g., "Tests", "Build & Test").Use the tags field in the request body (e.g., "tags": ["ci-fix", "pr-312"]) to track which CI failures have already triggered sessions and avoid duplicates.
3

What happens when CI fails

当一个 PR 的 CI 运行失败时,Action 会提取失败详情,并将其作为 session 提示传递给 Devin。以下是一个典型的自动修复流程:
  1. 读取 CI logs — Devin 打开运行 URL,并解析失败 job 中的错误输出、堆栈跟踪和测试结果
  2. 将错误追踪到代码 — 在 PR 分支上定位相关文件和行 (例如 UserList.tsx:34) ,并读取周边代码及最近的 diff
  3. 推送修复 — 直接向 PR 分支提交有针对性的更改,这会自动重新触发 CI
  4. 在 PR 上评论 — 发布摘要,说明 root cause 以及做了哪些更改
来自 Devin 的 PR 评论示例:
4

只针对合适的失败项

并非所有 CI 失败都适合自动修复——基础设施超时和 Docker 构建问题并不能单纯通过修改代码解决。添加一个条件,使只有相关的作业失败才会触发 Devin:

保持修复内容易于审查

Devin 会推送一个修复提交,但在合并之前,这个 PR 仍然需要人工审查。将自动修复视为开发者的起点,而不是代码审查的替代。如果 Devin 无法解决该失败,它会在 PR 上发表评论,说明它发现了什么,方便工程师在此基础上接手处理。