github的pr与actions事件恢复后，如何确认目标提交的检查是否真正完成？先把pr检查与具体工作流运行关联，再核对运行的headsha、状态和结论，最后查看相关job与step。2026年11月10日的git操作、pull requests及pr触发actions延迟事件已于北京时间11月11日01:55标记恢复；平台恢复不等于每个仓库的每次运行都已成功，也不能用一个旧提交的绿色检查代替新提交结果。
准备可读取目标仓库的GitHub CLI环境
以下示例要求已安装GitHub CLI，并使用具有仓库读取权限的账户正常登录。所有示例中的OWNER/REPO、PR_NUMBER、COMMIT_SHA和RUN_ID都需替换成真实目标，不是事件页编号。这些查询只读取检查与运行记录，不触发重跑。
先查看目标PR的检查，明确当前PR有哪些检查结果：
gh pr checks PR_NUMBER --repo OWNER/REPO
应看到与目标PR关联的检查。没有结果、检查仍在等待或检查失败是不同状态，不能统一当作平台仍然中断。若命令提示仓库或权限错误，应先确认仓库标识和当前账户访问权；错误信息本身不证明工作流没有运行。
用提交SHA筛选运行，再确认返回的是哪份代码
针对需要交付的完整提交SHA，读取对应运行列表：
gh run list --repo OWNER/REPO --commit COMMIT_SHA --limit 20 --json databaseId,workflowName,headSha,status,conclusion,event
结果中的databaseId是工作流运行标识，headSha是该运行对应的提交，status与conclusion分别描述运行状态和结果。空列表只代表本次筛选没有返回记录；不能立即判断所有任务都成功，也不能把另一个提交的成功结果拿来填补。
PR工作流可能涉及合并提交或不同触发上下文，因此筛选不到预期结果时，还需要结合PR检查所关联的实际运行及事件理解，而不是盲目把分支最新SHA当作所有工作流必定采用的SHA。CLI文档也明确，查看与PR关联的运行应使用gh pr checks。
查看具体运行的job和step
从列表取得实际RUN_ID后，可查询该运行摘要及步骤：
gh run view RUN_ID --repo OWNER/REPO --verbose
需要读取失败步骤日志时，使用对应查询：
gh run view RUN_ID --repo OWNER/REPO --log-failed
摘要有助于区分尚未完成的运行与已经结束的失败；日志则帮助判断失败是否发生在依赖安装、构建、权限或其他项目步骤。CLI获取日志可能受平台日志关联能力影响，部分日志不可用或步骤名为UNKNOWN STEP，不等于仓库没有执行过那些动作。
平台公告与仓库结果处在不同层次
事件hnf21m9jkl3c记录了Git操作与PR响应升高、PR触发的Actions延迟，并在后续更新中分别描述组件改善和整体恢复。某个组件先报告正常，不代表所有PR处理或积压工作已在同一秒完成；公告时间也不是每一个请求的精确故障起止。
这次事件已经恢复，后续仓库报错仍需要按提交与日志判断。状态页没有证明每个仓库都发生数据损坏，也不能据此断定源代码丢失或某种攻击。将官方事件作为时间背景，再以实际运行记录判断项目任务，才能避免把所有失败归给同一平台原因。
确认需要补跑，再决定执行范围
只有确认了目标运行、失败原因以及已有外部操作结果，才能进一步选择补跑。GitHub重跑会保留原事件的GITHUB_SHA、GITHUB_REF和原触发者权限，不会自动变成对当前分支最新提交的验证。首次运行后30天内、仓库写权限、工作流未禁用及最多50次重跑等条件，也属于重跑本身的限制。
因此，这套查询的完成标志是能够回答“哪个提交、哪次运行、哪些job、最终什么结果”，而不是只看到平台Resolved或某处绿色图标。读清记录再处理具体任务，既能减少重复执行，也能保留对目标提交是否通过的准确判断。
