GitHub Actions 怎么手动重跑单个失败任务

GitHub Actions 可以只重跑一个具体失败的 job：进入失败的 workflow run，在左侧 Jobs 区域找到目标 job，点击它旁边的重跑入口，按需启用调试日志，再确认 Re-run jobs。需要特别注意的是，这并不一定只启动一个节点——依赖该 job 的下游 jobs 也会一起重新运行。

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

准备运行记录：确认权限和重跑范围

先记下仓库、workflow 名称、失败 run、目标 job，以及它是否有下游依赖。GitHub 官方说明要求操作者拥有仓库写权限；workflow 或 job 可以在首次运行后的 30 天内重跑，且日志不能已经超过保留期限。一次 workflow run 最多允许重跑 50 次，这个次数同时计算整次重跑与部分 job 重跑。

如果目标是 test，而 deploy 通过 needs: test 依赖它，那么选择重跑 test 时，新的 attempt 会包含 test 和 deploy。此前已成功且不依赖它的 build 不需要再次执行，其输出仍可供新的 attempt 使用。

第一步：选择 Actions 入口和失败 run

1. 打开目标仓库主页，点击仓库名称下方的 Actions 标签。
2. 在左侧 workflow 列表中选择目标 workflow，例如 Build and test。
3. 在 Workflow runs 列表中点击红色 Failed 的那次运行名称。

成功进入后，页面应显示 workflow run summary；左侧能看到 Jobs 区域，中央能看到提交、分支、触发时间和运行状态。不要停留在 workflow runs 列表页，因为单个 job 的重跑入口在具体 run 里面。

第二步：映射并选中要重跑的具体 job

1. 在左侧 Jobs 区域找到红色失败状态的 job。
2. 先点击 job 名称，确认中央日志中的失败步骤就是本次要修复的目标。
3. 回到该 job 行，点击其旁边的重跑图标或操作入口，而不是右上角的 Re-run failed jobs。

这一步的判断标准很简单：你应当看到目标从“整个 run”缩小到一个明确 job，例如 test。如果页面只提供右上角下拉菜单中的 Re-run failed jobs，先检查是否选中了具体 job，或当前账号是否有仓库写权限。

第三步：预览影响范围并提交重跑

打开重跑确认层后，核对显示的目标 job。若上一次失败信息不足，可以勾选 Enable debug logging。它会为本次重跑启用 runner diagnostic logging 和 step debug logging，适合定位环境、表达式、权限或 runner 侧问题；正常情况下不要长期默认开启，以免日志变得过于冗长。

1. 确认目标 job 名称无误。
2. 根据排障需要决定是否启用 Enable debug logging。
3. 点击主按钮 Re-run jobs 提交。

重跑不是用当前操作者身份重新触发一次新事件。GitHub 会继续使用原始事件的 GITHUB_SHA 和 GITHUB_REF，权限上下文也取自最初触发 workflow 的 actor，而不是点击重跑的人。这意味着：如果代码已经在后续提交中修复，直接重跑旧 attempt 仍然针对原来的提交；想验证新代码，应让新提交触发新的 workflow run。

第四步：核对新的 attempt 和下游任务

提交后，页面会进入新的 attempt。先观察目标 job 是否从 queued、in progress 进入 success，再确认依赖它的下游 jobs 是否按预期启动。此前成功 jobs 的输出、原始运行产生的 artifacts，以及此前已通过的 deployment protection rules，官方说明都可在相应重跑中继续使用。

1. 查看目标 job 顶部状态和失败步骤是否消失。
2. 展开新的日志，确认修复点而不是偶然通过。
3. 检查依赖目标 job 的下游 jobs 是否重新运行并完成。
4. 需要对比时，在运行名称右侧打开 Latest 下拉菜单，切换到之前的 attempt。

CLI 方式：已知 JOB_ID 时直接重跑

如果团队日常使用 GitHub CLI，可以通过具体 JOB_ID 执行同一类操作。注意 --failed 是“所有失败 jobs”，而 --job 才是“某个具体 job”。

# 查看最近的 workflow runs，先取得目标 RUN_ID
gh run list --workflow "Build and test"

# 查看某次运行的 job 信息，从输出中确认目标 JOB_ID
gh run view RUN_ID

# 只重跑指定 JOB_ID；其依赖者仍可能随之运行
gh run rerun --job JOB_ID

# 需要更详细排障信息时，为本次重跑启用调试日志
gh run rerun --job JOB_ID --debug

CLI 命令提交后，可以用 gh run watch 观察运行进度；这属于替代入口，不影响网页操作中的范围判断原则。

异常处理：为什么看不到单个 job 的重跑入口

• 没有写权限：只有拥有仓库写权限的人才能重跑 workflow 或 job。
• 运行过旧：首次运行超过 30 天后不能再重跑；日志超过保留期限也无法重跑相应 jobs。
• 已达到次数限制：同一 workflow run 的全部与部分重跑合计最多 50 次。
• 选错页面：必须先进入具体 workflow run summary，再从 Jobs 区域选择 job。
• 把 step 当 job：GitHub 支持重跑 job，不支持只重跑 job 内的单个 step。

结果核对清单

相关问题

单个 job 重跑后，依赖它的 deploy 会不会一起跑

会。官方说明中，重跑一个具体 job 时，依赖它的 jobs 也会在新的 workflow run attempt 中启动。

可以只重跑失败 step 吗

不可以。重跑粒度是 job，不是 job 内部的 step。若想缩短成本，需要重新拆分 workflow 的 job 边界。

为什么修复代码后重跑仍然报原来的错

因为重跑沿用最初事件的 GITHUB_SHA 和 GITHUB_REF。后续提交不会自动替换旧 run 的代码版本，应触发一条新的 workflow run。

重跑失败 jobs 和重跑单个 job 有什么区别

Re-run failed jobs 会选择所有失败 jobs；单个 job 入口只选择目标 job，但两者都会带上各自依赖关系中的下游 jobs。