GitHub Actions 失败步骤怎样只重新运行未完成的任务

GitHub Actions 里一个 workflow run 失败时，通常不需要把已经成功的 job 再跑一遍。正确的入口是 Re-run failed jobs：它会重新排队失败的 job 及其必要依赖，成功 job 保持原结果。要注意，这不是从失败 step 的下一行继续执行；失败 job 会重新从头跑，因此前置 checkout、安装依赖等步骤也会再次发生。

官方地址：https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs

为什么失败步骤不能从断点继续

GitHub Actions 的执行单位是 job。一个 job 由多个 step 组成，step 失败后，该 job 结束；重新运行时，GitHub 会重新创建这个 job 的执行环境，再按顺序执行步骤。已经成功的其他 job 不会因为选择失败重跑而自动重复。

因此，先在运行摘要里确认范围：如果只有 test-linux 失败，优先重跑它；如果失败 job 依赖一个被跳过的上游 job，重跑范围可能还会包含依赖关系。若需要清空所有 job 的状态，才选择全量重跑。

在 Actions 页面只重跑失败的 jobs

第1步：打开运行摘要。进入仓库的 Actions，在左侧选择对应 workflow，再点击失败的运行记录。确认中间的 Jobs 区域能看到失败 job 和失败原因。

第2步：打开重跑菜单。在运行摘要右上角点击 Re-run jobs，不要直接选 Re-run all jobs。

第3步：选择失败重跑。点击 Re-run failed jobs，必要时勾选 Enable debug logging，然后确认 Re-run jobs。提交后页面会产生一个新的运行尝试，失败 job 会显示排队或进行中。

如果菜单里没有该项，先确认当前账号有仓库写权限，并检查这次运行是否已经超过官方允许的重跑期限。运行记录仍可查看，不代表仍然可以提交重跑。

用 gh CLI 重跑并确认新 attempt

在已登录并有仓库权限的 GitHub CLI 环境中，拿到运行记录的数字 ID 后执行：

# 只重跑指定 workflow run 中失败的 jobs
gh run rerun RUN_ID --failed

# 需要更详细的 runner 与 step 调试日志时再打开 --debug
gh run rerun RUN_ID --failed --debug

# 观察重跑进度；RUN_ID 替换为实际运行编号
gh run watch RUN_ID

--failed 是范围开关，不能把它理解为“从某个失败 step 继续”。如果只想针对单个 job，可以在网页 Jobs 区域使用该 job 旁的重跑操作，或根据该 job 的 ID 使用 CLI 的 --job JOB_ID。

第4步：确认结果。回到运行详情，打开 attempt 选择器，进入新 attempt；先看目标 job 是否从 queued 变为 in progress，再看最终是否显示 Success。仍失败时只分析新 attempt 的日志，因为旧日志只能解释第一次失败。

什么时候应该改成全量重跑

GitHub 官方文档还规定：workflow run 通常只能在初次运行后 30 天内重跑，重跑次数最多 50 次；重跑沿用初始触发者的权限，以及原事件对应的 GITHUB_SHA 和 GITHUB_REF。所以重跑前要确认权限和代码版本，而不是把它当成一次新的 push。

相关问题

失败的是一个 step，为什么前面的 step 也会再执行？

因为重跑粒度是 job。GitHub 会重新创建 job 环境，不能从失败 step 之后恢复进程内状态。

重跑失败 jobs 会不会重新执行成功的 job？

正常情况下不会；但失败 job 的依赖关系可能影响哪些 job 被重新纳入范围，最终以运行摘要为准。

为什么重跑后仍然使用旧提交？

重跑沿用原 run 的 SHA 和 ref。要验证新代码，应创建新的提交或新的 workflow run，而不是反复重跑旧记录。