CI Fix 用于诊断 GitHub Actions 的 CI 失败并实施修复，采用最小化、有针对性的差异改动，将修复推送到专用分支而不创建 PR。
前置条件
在继续之前，验证 GitHub CLI 认证状态：
gh auth status
如果未认证，需先让用户运行 gh auth login。
工作流程
1. 定位失败的运行
确定失败的 workflow run。如果在 PR 分支上工作：
gh pr view --json statusCheckRollup --jq '.statusCheckRollup[] | select(.conclusion == "FAILURE")'
如果从分支或 run ID 工作：
gh run list --branch <branch> --status failure --limit 5
gh run view <run-id> --verbose
2. 提取失败日志
从失败步骤拉取日志以识别根本原因：
gh run view <run-id> --log-failed
如需更深入检查：
gh run view <run-id> --log --job <job-id>
gh run download <run-id> -D .artifacts/<run-id>
3. 识别根本原因
分析日志中的常见失败模式：
- 构建/编译错误：缺少依赖、类型错误、语法问题
- 测试失败：断言失败、超时、不稳定测试
- Lint/格式化：风格违规、未使用的导入
- 环境问题：缺少 secrets、权限、资源限制
优先选择能解决问题的最小修复。确定性的代码修复优于工作流管道改动。
4. 实施修复
进行最小化、范围明确的改动，匹配仓库现有风格：
- 只修复损坏的部分——避免无关重构
- 尽可能将改动限制在失败的 job/step 内
- 如果修改工作流文件，保留现有权限，避免扩大 token 访问范围
5. 推送到修复分支
创建或更新专用修复分支：
git checkout -b ci-fix/<original-branch>
git add -A
git commit -m "fix: resolve CI failure in <job-name>
Co-Authored-By: Warp <agent@warp.dev>"
git push -u origin ci-fix/<original-branch>
如果修复分支已存在，更新它：
git checkout ci-fix/<original-branch>
git pull origin <original-branch>
# make fixes
git commit -m "fix: <description>
Co-Authored-By: Warp <agent@warp.dev>"
git push
6. 验证修复
在修复分支上触发 CI 并监控：
gh run list --branch ci-fix/<original-branch> --limit 1
gh run watch <new-run-id> --exit-status
仅重新运行失败的 job：
gh run rerun <run-id> --failed
安全注意事项
- 除非明确要求，避免使用
pull_request_target——它可能将 secrets 暴露给不受信任的代码 - 保持工作流权限最小化；不要为了通过测试而扩大访问范围
- 对于不稳定测试，优先采用确定性修复而非盲目重跑
交付物
修复后，提供简要总结：
- 失败的运行：链接或 ID
- 根本原因：什么坏了以及为什么
- 修复：改动了什么
- 验证：显示绿色状态的新运行链接