写过CI的人都踩过这个坑——某天runner突然停了才知道版本过期了，今天这件事被一个API彻底原生化了

写过 CI 的人都踩过这个坑——某天早上打开 GitHub，一看，全是红的。查了半天，发现是 runner 版本被 GitHub悄悄停用了，而你根本不知道它哪天会停。

这不是流程问题，是接口问题。

2026 年 9 月 3 日，GitHub Actions 推送了九月更新，三件事每一件都指向同一个方向：把 CI 里那些「本该透明的事实」变成可查询的接口。

第一件事：Runner 版本哪天停用，现在可以查了

以前团队问「这个 runner 版本还能用多久」，答案要么是「看文档」、要么是「等它崩了再说」。没有任何程序化的方式提前知道。

现在，GitHub 提供了一个新 REST API：

GET /actions/runners/deprecations/{version}

在仓库、组织、企业三级都可以调，返回三个时间戳：

• runner_version：具体版本号
• runtime_deprecates_at：运行时支持结束日期
• registration_deprecates_at：注册截止日期

也就是说，你可以在 dashboard 上跑一个定时任务，每次跟这两个时间比对，提前 N 天发告警，而不是等它炸了才救火。

这对有大量自托管 runner 的团队尤其重要——不是 GitHub 代管的那批，是你自己机器上跑的。版本管理靠文档靠口口相传，天然是事故高发区。

第二件事：读取漏洞警报，现在不需要开写权限了

以前 workflow 想读一下 Dependabot 漏洞警报，必须给 GITHUB_TOKEN 加上 security-events: write 或者更宽的 scope。等于是「想读新闻，需要一张可以改新闻的记者证」。

新版本新增了 vulnerability-alerts 权限，只读，值可以是 read 或 none。

最小权限原则喊了多少年，这个 scope 一直是缺口。现在你终于可以这样写：

permissions:
  vulnerability-alerts: read   # 只读，不再需要 write

这个改动看起来小，但它补上了 CI 安全审计的最后一环——能够把漏洞治理接进自动化流程，同时不需要为读数据而开放写权限。

第三件事：可复用 workflow，现在知道自己是谁了

可复用 workflow（reusable workflow）有个长期问题：被 A 仓库调用时，日志里显示的是 A；被 B 仓库调用时，日志里显示的也是 A——因为 github.workflow_ref 指向的是调用方，不是定义方。

九月更新新增了四个 job context 属性，专门解决这件事：

• job.workflow_ref：定义当前 job 的 workflow 文件完整 ref
• job.workflow_sha：定义文件的 commit SHA
• job.workflow_repository：定义文件所在仓库（owner/repo）
• job.workflow_file_path：文件相对路径

原来的 github.workflow_ref 和 github.workflow_sha 指向调用方，新属性指向定义方。只有在直接写在 workflow 文件里的 job，两者才一致。

这意味着：如果你维护一个内部可复用 workflow 库，现在可以精确追溯「这个 job 跑在哪次提交上、属于哪个仓库定义的版本」——供应链审计的核心数据。

三件事的共同逻辑

看起来功能独立，但方向一致：把 CI 中原本靠文档、靠记忆、靠事故才能知道的事实，变成接口可以查、workflow 可以用的数据。

• Runner 版本生命周期 → 以前靠文档，现在靠 API
• 漏洞警报权限 → 以前靠宽 scope，现在靠最小权限
• 可复用 workflow 身份 → 以前靠日志猜测，现在靠结构化属性

这不是功能更新，是CI 可观测性的基础设施建设。

怎么落地

两件事可以这周做：

第一件：给自托管 runner 写一个版本监控 job，每周跑一次，把 runtime_deprecates_at 接近当前日期的版本捞出来发告警。这个数据 GitHub 以前不提供，现在提供了，不用白不用。

第二件：把涉及 Dependabot 漏洞警报的 workflow 全部检查一遍，把 security-events: write 降级成 vulnerability-alerts: read。不影响功能，但缩小了 token 权限。

CI 的可靠性不是靠某一次大重构，而是靠这些「本该早就有的接口」一点点补齐。