GitHub Actions重跑失败作业会使用最新代码吗

GitHub Actions重新运行只适用于已经存在的运行记录。它沿用原始事件的提交SHA和引用，不会自动切换到分支最新代码；完全没有创建运行的漏触发事件，也不能靠一个不存在的RUN_ID执行重跑。事故后处理时，先确认对象，再选择重跑范围并读取新尝试结果。

重跑之前确认已有运行和原始提交

适用环境为已安装并认证的GitHub CLI终端。OWNER/REPO替换为真实仓库，RUN_ID替换为已经存在的运行ID；读取需要相应访问权限，真正重跑需要仓库写入权限。以下代码是官方命令用法示例，不代表已经替任何仓库执行。

gh run view RUN_ID --repo OWNER/REPO --json databaseId,headSha,headBranch,event,status,conclusion,attempt

预期读取单次运行对象，核对headSha、分支、事件和当前结论。运行对象不存在或权限不足时，应处理具体错误，不能虚构一个运行ID继续。重跑沿用首次触发者的权限和原始GITHUB_SHA、GITHUB_REF，因此它验证的是原始事件，不等于重新测试后来推送的代码。

只重跑失败作业也会带动依赖作业

对于已确认需要重跑的失败运行，可选择失败作业范围。执行前应理解自己的工作流是否含部署、通知、制品发布等实际效果；重复执行可能再次发生这些效果，不能仅因服务已恢复就给所有运行无条件补跑。

gh run rerun RUN_ID --repo OWNER/REPO --failed

预期是请求重跑失败作业及依赖它们的作业，不是立刻保证工作流成功。没有纳入重跑范围的作业保留上次尝试的输出，新作业可以使用这些输出。该入口也不是用于凭空创建此前从未启动的PR事件运行。

提交重跑请求之后核对新尝试

使用相同RUN_ID读取结果，观察attempt、status和conclusion。调用成功只是提出了重跑请求，需要以实际运行结果确认完成，不能把请求已受理写成测试已通过。

gh run view RUN_ID --repo OWNER/REPO --json databaseId,attempt,status,conclusion,headSha,url

预期得到更新后的尝试和状态；仍在排队或执行时没有最终成功结论。官方允许在初次运行后30天内重跑，每次运行最多重跑50次，包含整次及部分作业重跑；工作流处于禁用状态时不能重跑。这些边界与仓库自己是否需要重新执行是不同问题。

漏触发与已有失败运行为什么不能混用结论

11月10日约15:00至17:55 UTC的GitHub事故中，约1.8%的事件出现工作流延迟，峰值约7%；另约0.09%的PR事件未启动工作流，需要重新触发。前者和后者的分母不同，也不能把“需要重新触发”机械等同于对任意失败运行使用--failed。

本次共享Git基础设施承受了增加的后台分析及合并计算压力。GitHub关闭近期合并处理优化、暂停后台分析并限制低优先级流量来缓解；后台处理在总体恢复后继续追赶。复盘指出的残留现象提醒使用者区分运行是否存在、是否结束及结果是否正确，按具体证据处理。