写过 CI 的人都踩过这个坑——runner 什么时候过期只能靠等崩，今天 GitHub 用一个 API 把这件事彻底透明了

写过 CI 的人都踩过这个坑——runner 什么时候过期只能靠等崩，今天 GitHub 用一个 API 把这件事彻底透明了

写过 CI 的人都踩过这个坑——配了三个月自托管 runner，突然有一天 pipeline 挂了，翻日志才发现是 runner 版本不支持了。自托管 runner 的问题就在这：GitHub 托管 runner 会自动更新，但自托管的要自己管，等你知道版本过期了，往往已经影响了生产。

2026 年 9 月初，GitHub Actions 发了三个更新，直指这个日常被忽略的运维盲区。

第一个：runner 版本弃用 API

以前想查某个 runner 版本什么时候停服，只能靠 GitHub 文档、靠升级公告、自己记录。现在一个 REST API 搞定：

GET /actions/runners/deprecations/{version}

在仓库、组织、企业三级都能调，返回三个时间点：

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

实际用起来就是这样——查一下 2.327.0 什么时候过期：

curl -H "Authorization: token $GITHUB_TOKEN" 
  "https://api.github.com/actions/runners/deprecations/2.327.0"

返回结果里直接告诉你「这个版本 X 月 X 日停止接收新任务，Y 月 Y 日彻底不可用」。接进你们的升级看板或者 Slack 告警，runner 过期变成一个可预期的计划事件，而不是突发故障。

这个 API 的价值是双重的：一是给运维团队一个提前量的窗口，不用等崩了再救；二是配合前面提到的最小权限 token 工作流，可以把 runner 生命周期管理自动化。

第二个：GITHUB_TOKEN 新增 vulnerability-alerts 权限

以前 workflow 想读 Dependabot 告警，token 要么给 security-events: read，要么给更高的权限范围——对于一个只读告警的工作流来说，权限开太大了。

现在 GitHub 新增了 vulnerability-alerts 权限，只控制 Dependabot 告警的读取权限：

permissions:
  vulnerability-alerts: read  # 或者 none

这个权限的粒度是专门为 Dependabot 告警设计的，符合最小权限原则。实际场景：CI 里跑一个定期检查依赖漏洞的 job，用这个权限就够了，不用再开 security-events 那套。

结合前面的 runner 版本 API，你们的 workflow 现在可以做到：定期查 runner 版本是否即将过期 + 查依赖是否有 Dependabot 告警，两个安全检查都走最小权限 token。

第三个：可复用工作流新增四个 job context 属性

可复用工作流有个长期问题：被调用时，workflow 文件来自另一个仓库，但 github.workflow_ref 和 github.workflow_sha 反映的是调用方 workflow 的信息，不是定义当前 job 的那个 workflow 文件。

三个新属性解决了这个问题：

• job.workflow_ref：当前 job 所在 workflow 文件的完整 ref
• job.workflow_sha：当前 job 所在 workflow 文件的 commit SHA
• job.workflow_repository：当前 job 所在 workflow 文件所属的仓库
• job.workflow_file_path：workflow 文件在仓库根目录下的路径

直白说：如果你写了一个通用的共享 workflow，被多个上游仓库调用，现在可以在 workflow 内部精确知道「我是从哪个文件哪个版本被调进来的」，而不是只能看调用方的信息。

实际用途：做审计日志、做权限校验、做跨仓库 workflow 来源追踪，都用得上。

注意：这个新属性在 GitHub Enterprise Server 上不可用，如果你们用 GHES，需要降级处理。

三个更新，一条主线

这三个更新看似独立，背后是同一个思路：给 CI/CD 团队提供更强的可见性和控制力。runner 版本 API 解决的是「基础设施什么时候过期」的可预测性；vulnerability-alerts 权限解决的是「workflow 权限能不能更小」的安全性；job context 属性解决的是「复用 workflow 的来源能不能追踪」的可追溯性。

三个问题都是运维日常被卡脖子的地方，但以前没有工具级的原生解法。现在 GitHub 自己在把这个能力补上。

怎么落地

如果你们在用自托管 runner，第一件事把 GET /actions/runners/deprecations/{version} 接进监控，设定一个提前量告警（比如过期前 30 天提醒），这比等 pipeline 挂了再查原因省心得多。

如果 workflow 里要读 Dependabot 告警，把 security-events 权限替换成 vulnerability-alerts: read，权限更小，审计更容易。

可复用 workflow 那边，先检查你们目前有多少跨仓库调用，确认是否需要用新的 job context 属性做来源追踪。

这三个功能都不复杂，但日常加起来省的心力不少——runner 什么时候过期这件事，终于不用靠玄学判断了。