GitHub Actions如何按提交SHA检查工作流是否启动

GitHub事故后判断某次提交的Actions有没有启动，可以先用GitHub CLI按提交SHA和触发事件读取运行记录，再查看实际运行的状态与结论。查到queued不等于漏触发，查到completed也不自动等于成功；没有查到记录仍需要排除筛选、权限与工作流触发条件。

先限定仓库和需要检查的提交

以下命令用于已安装并完成GitHub CLI认证的终端，需要对目标仓库及Actions运行记录具有读取权限。OWNER/REPO替换为仓库所有者和名称，COMMIT_SHA替换为需要核对的完整提交SHA，不使用分支名冒充固定提交。示例仅展示查询方法，没有读取任何用户私有仓库。

gh run list --repo OWNER/REPO --commit COMMIT_SHA --event pull_request --limit 100 --json databaseId,headSha,event,status,conclusion,createdAt,url

预期结果是JSON数组，各项包含运行ID、提交、事件、状态和结论。--event限定拉取请求事件；如果实际工作流依赖push等其他事件，这个筛选本来就不会列出它们。默认查询只取近期有限记录，因此示例将上限设为100，仍不代表穷尽所有历史。

查到运行后单独读取状态

把上一步databaseId对应的真实数字替换RUN_ID，读取该次运行，而不是凭工作流显示名称猜ID。下面命令继续只读，不会启动或重跑任务。

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

预期得到单次运行对象。status反映运行阶段，conclusion表示结束后的结论；进行中的运行可能没有最终结论。对照headSha可减少把其他提交的成功运行误算到本次提交的风险，attempt则帮助区分同一次运行的多次尝试。

空数组为什么不能直接证明漏触发

查询为空只能说明在当前仓库、权限、筛选条件和结果范围内没有记录。PR相关运行涉及实际事件提交，不能未经核对就把源分支当前最新SHA视为所有工作流必然使用的SHA。禁用的工作流、事件条件、路径或分支过滤也需要结合仓库自己的配置理解。

如果命令报错，错误输出与正常返回空数组是不同结果。缺少权限、认证失败或网络问题都不能解释成“GitHub确认没有运行”。反过来，查到记录也需要看具体状态和结论，不能只计数。

事故比例用于理解范围，不用于替代仓库检查

11月10日约15:00至17:55 UTC的事故中，约1.8%的事件出现Actions延迟，峰值约7%，通常延迟1.5至3.5分钟、最长约10分钟；另有约0.09%的拉取请求事件没有启动工作流，需要重新触发。百分比的分母不同，不能用它们推算某个仓库必然漏掉多少次运行。

这次根因是共享Git基础设施过载，后台分析与PR合并计算给用户请求增加压力。服务恢复后后台仍在追赶，部分PR继续显示较早的源分支提交。只读查询的作用是拿到具体运行事实，为后续处理提供依据，不是自动修复所有遗漏。