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 > Devin API > Service users and create a service user with a role that includes the Use Devin sessions (UseDevinSessions) permission — creating sessions requires this permission, and ManageOrgSessions alone does not grant it
  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, shown at the top of the Settings > Devin API page)
请确保该代码仓库已在 Devin 的 Machine 上完成配置,以便 Devin 可以克隆、构建并向其推送代码。
2

添加工作流程文件

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 上发表评论,说明它发现了什么,方便工程师在此基础上接手处理。