GitHub Actions 故障诊断

要解决什么问题

GitHub Actions 的 CI 流水线挂了，但默认报错通常只告诉你一个 exit code 1。具体是哪个步骤、哪条命令、哪个条件判断触发了失败，得自己翻几十页日志。更头疼的是：这到底是偶发抖动还是最近引入的回归？有没有人已经在修了？

核心能力

gha 技能通过 gh CLI 自动化这一排查流程，关键步骤包括：

• 精确定位失败点：读取完整日志，区分非致命警告和真正导致 exit code 1 的逻辑判断，比如 failing:、fatal: 或脚本中的条件退出。
• 检查抖动模式：针对同一个 job（而非整个 workflow）拉取最近 10–20 次运行记录，计算成功率，判断是一次性故障还是持续复发。
• 追溯引入故障的提交：找到该 job 最后一次通过与第一次失败之间的分界提交，交叉验证之后所有运行都失败、之前都通过后，才高置信度标记为 breaking commit。
• 根因分析：结合日志、历史运行和 breaking commit，给出导致失败的直接原因，而非简单罗列所有报错。
• 查找已有修复 PR：用错误信息或文件名搜索 open PR，若已有修复在途则在报告中注明并跳过建议部分。

适用边界

• 依赖 gh CLI 已登录且有权限访问目标仓库。
• 历史数据深度取决于 GitHub 保留的运行记录范围。
• 根因分析基于日志和时间线推断，无法保证 100% 准确；对于外部依赖（如第三方 API 超时）导致的偶发失败，可能只能归类为"非代码回归"。