GitHub Actions恢复后如何用Python区分等待、成功和其他运行结果

GitHub Actions恢复后，如何用Python区分仍在等待、已经成功和需要继续核查的运行？先由GitHub CLI导出明确仓库的运行JSON，再按status判断是否结束，按conclusion区分结束结果，同时保留运行ID和提交SHA。不要把conclusion为空当作失败，也不要把平台事件Resolved当作所有运行成功。2026年11月10日的Git、PR及PR触发Actions延迟事件已恢复，这个方法用于仓库记录整理，不是判断当前平台仍在中断。

导出范围明确的运行记录

准备已正常登录、具有目标仓库读取权限的GitHub CLI，以及Python 3.10或更新版本。将OWNER/REPO换成实际仓库，在准备保存本地记录的目录执行下列只读查询：

gh run list --repo OWNER/REPO --limit 20 --json databaseId,workflowName,headSha,status,conclusion,event > runs.json

正常结果会写入runs.json，内容是最多20次近期运行组成的数组。这个数字是查询上限，不是整个仓库的任务总数。命令若提示认证、访问或网络错误，不应把未成功取得的文件交给脚本，或者把空文件当成“没有失败”。

按完成状态分类，不把空结果误判成失败

以下完整脚本读取刚才的文件，只输出分类及运行身份，不发起重跑，也不访问GitHub。它把尚未completed的运行列为“尚未完成”，已完成且success列为“成功”，其余已完成结果保留原结论供人工判断。

python - <<'PY'
import json
from pathlib import Path

runs = json.loads(Path("runs.json").read_text(encoding="utf-8"))
if not isinstance(runs, list):
    raise SystemExit("预期runs.json是运行数组，请核对导出是否成功。")

for run in runs:
    status = run.get("status")
    conclusion = run.get("conclusion")
    if status != "completed":
        group = "尚未完成"
    elif conclusion == "success":
        group = "成功"
    else:
        group = "已结束，需按结论判断"
    print(json.dumps({
        "group": group,
        "run_id": run.get("databaseId"),
        "workflow": run.get("workflowName"),
        "commit": run.get("headSha"),
        "status": status,
        "conclusion": conclusion,
        "event": run.get("event")
    }, ensure_ascii=False))
PY

应看到每次运行的一行JSON。failure、cancelled、timed_out、skipped等结论不能全部归为同一种失败，脚本因此保留具体值。尚未完成的运行也可能处于queued、in_progress或其他中间状态；归入同一观察组并不抹去status字段中的区别。空数组不会输出运行行，只表明本次输入没有记录。

保留提交SHA，避免统计与交付对象错位

同一工作流可能在不同提交上连续执行，同一提交也可能关联不止一项检查。运行ID用于定位某次运行，headSha标识对应提交，二者都不应被工作流名称替代。统计里出现一个成功结果，不代表当前分支最新提交已经通过。

需要继续查看某个分类结果时，将该行run_id作为RUN_ID，并替换仓库名：

gh run view RUN_ID --repo OWNER/REPO --verbose

应查看到具体job和step摘要，再结合项目任务判断是否有后续处理需要。PR关联检查与普通运行列表也有上下文区别，不能只凭最近20条记录覆盖所有PR判断。

恢复事件提供背景，不替代项目结果

事件hnf21m9jkl3c在北京时间2026年11月11日01:55标记恢复，此前涉及Git操作与PR响应变慢，以及PR触发的Actions延迟。各组件改善与整个事件关闭的公告时间并不相同，不能把某条更新视为每个仓库任务同步结束的证明。

上面的整理方法可以保留仓库、运行、提交和结果这几类信息，但无法从JSON自动证明失败原因属于平台。构建错误、依赖问题和权限问题仍需相应日志支持，也不能从恢复事件推导源代码丢失、数据损坏或已发生攻击。

分类结果不是自动重跑清单

GitHub重跑要求仓库写权限，受首次运行后30天、最多50次及工作流未禁用等限制。重跑沿用原触发者权限与原事件GITHUB_SHA、GITHUB_REF；重跑失败或指定job时，依赖job也会重跑。对部署和外部操作而言，这些语义会影响是否重复执行。

因此，脚本有意只整理记录。它帮助看清哪些任务未完成、哪些成功、哪些结论需要进一步判断，而不把“非success”直接变成需要执行的补跑操作。明确目标提交与实际运行结果，才是恢复后仓库验收的基础。