GitHub Actions如何只重跑失败任务并避免用错job编号

GitHub Actions如何只重跑失败任务，而不是再次执行整条工作流？确认实际运行与失败原因后，可用gh run rerun RUN_ID --failed；它会重跑失败job及其依赖链中的后续job，不代表只执行一个孤立步骤。要补跑指定job，应先取得该job的databaseId，再用--job参数。重跑保留原事件的提交、引用和原触发者权限，因此不是验证当前分支最新提交的快捷方式。

先确认重跑资格与原运行身份

GitHub允许在首次运行后的30天内重跑，需要仓库写权限，且工作流不能处于禁用状态。每次运行最多可重跑50次，完整重跑和部分job重跑都计入限制。下面示例要求GitHub CLI已正常登录，OWNER/REPO、RUN_ID和JOB_ID分别替换为真实仓库、运行ID和job数据库ID。

先只读查看原运行的提交与状态：

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

应看到原运行的数据库ID、headSha、触发事件及尝试次数等信息。运行ID不能用状态页事件编号替代。涉及发布、部署或其他外部操作时，已有操作结果也属于选择重跑范围的依据；工作流失败不等于此前所有外部动作都未发生。

只重跑失败job时使用failed选项

确定要补跑原运行中的失败任务时，执行：

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

这条命令会请求实际重跑，不是只读查询。GitHub也会重跑依赖这些任务的job；未包含的job保留上一次输出，新尝试可以使用这些输出。因此，部分重跑的执行范围不能仅看一个失败job的名称，还需要理解工作流依赖关系。

命令被接受不等于新尝试已经成功。它只说明重跑请求进入处理，最终仍需要查看运行结果。对存在外部写入的任务，应在执行前确认相应动作是否适合再次发生，不把平台恢复当作所有操作都可以无差别重复的理由。

指定job要用数据库ID，不用浏览器地址中的数字

CLI手册特别说明，浏览器job地址末尾的数字不能直接作为--job参数，否则可能返回404。先从实际运行查询正确的job名称与databaseId：

gh run view RUN_ID --repo OWNER/REPO --json jobs --jq '.jobs[] | {name, databaseId}'

从结果中找到目标job，将它的databaseId填入JOB_ID，然后才选择这一条补跑方式：

gh run rerun RUN_ID --repo OWNER/REPO --job JOB_ID

这是与--failed不同的范围选择，不需要为了“保险”把两种命令连续执行一遍。指定job重跑同样会涉及依赖它的job。正确数据库ID、仓库标识和对应RUN_ID需要属于同一目标，不能把不同运行的标识拼在一起。

重跑仍使用旧提交和原触发者权限

GitHub重跑沿用原事件的GITHUB_SHA和GITHUB_REF，并使用最初触发工作流的人的权限，不使用发起重跑者的权限替代。即使分支后来已有新提交，旧运行重跑成功也不能证明新提交通过。

如果问题来自代码或工作流内容已改变，应先明确需要验证的提交，而不是把旧运行的结果当作新内容结果。重跑主要是对原运行进行新的尝试，不会因为重新点击或发出CLI命令，就自动改写其触发上下文。

观察最终结果，区分请求接受与执行完成

发出一次选定范围的重跑请求后，可查看同一运行的进展：

gh run watch RUN_ID --repo OWNER/REPO --exit-status

这个命令持续显示进展直到完成，运行失败时以非零状态退出。当前CLI不支持用细粒度PAT认证此观察命令，属于手册说明的认证限制；不能因观察命令认证失败就认定任务没有执行。必要时仍应通过具备权限的正常方式读取实际运行结果。

历史平台事件不能替代这次运行的验收

事件hnf21m9jkl3c涉及Git操作、PR响应及PR触发Actions延迟，已于北京时间2026年11月11日01:55标记恢复。它说明平台事件已结束，不说明某个仓库补跑已经成功，也不能把后续所有项目错误都归入这次事件。

重跑后的判断仍应回到具体运行、目标提交、job结果与外部动作状态。明确范围后只发出需要的一次重跑，再核对最终结果，才不会把恢复后的补偿变成重复执行或对错误提交的验证。