名称: ci-fix 描述: 诊断并修复GitHub Actions CI失败。检查工作流运行和日志，识别根本原因，实现最小修复，并推送到修复分支。在CI是失败、红色、损坏或需要诊断时使用。许可证: MIT

CI修复

诊断CI失败并实现最小、有针对性的修复。将修复推送到专用分支而不创建PR。

前提条件

在继续之前验证GitHub CLI认证：

gh auth status

如果未认证，指示用户先运行gh auth login。

工作流程

1. 定位失败运行

确定失败的工作流运行。如果在PR分支上工作：

gh pr view --json statusCheckRollup --jq '.statusCheckRollup[] | select(.conclusion == "FAILURE")'

如果从分支或运行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. 识别根本原因

分析日志中的常见失败模式：

构建/编译错误：缺失依赖项、类型错误、语法问题
测试失败：断言失败、超时、不稳定的测试
代码检查/格式化：样式违规、未使用的导入
环境问题：缺失密钥、权限、资源限制

优先选择能解决问题的最小修复。确定性代码修复比工作流修改更好。

4. 实施修复

进行最小、范围匹配仓库现有样式的更改：

只修复坏的部分——避免不相关的重构
尽可能保持更改到失败的工作/步骤
如果修改工作流文件，保留现有权限并避免扩展令牌访问

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>
# 进行修复
git commit -m "fix: <描述>

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

重新运行仅失败的工作：

gh run rerun <run-id> --failed

安全注意事项

避免使用pull_request_target，除非明确请求——它可能将密钥暴露给不受信任的代码
保持工作流permissions:最小化；不要为了测试通过而扩大访问
对于不稳定测试，优先确定性修复而不是盲目重运行

可交付物

修复后，提供简要摘要：

失败运行：链接或ID
根本原因：什么坏了，为什么
修复：改变了什么
验证：显示绿色状态的新运行链接

名称: ci-fix 描述: 诊断并修复GitHub Actions CI失败。检查工作流运行和日志，识别根本原因，实现最小修复，并推送到修复分支。在CI是失败、红色、损坏或需要诊断时使用。 许可证: MIT