2026年了，GitHub 终于知道告诉你 runner 哪天停用了

写过 CI 的人都踩过这个坑——某天早上 workflow 突然全红了，runner 报错版本不再支持，然后翻遍 GitHub 文档也找不到这个版本哪天停用的。只能一边临时降级，一边等 GitHub 在某个角落发个公告。

2026 年 9 月，GitHub 给这个坑填上了。一个新的 REST API，可以直接查到任意 runner 版本的注册截止时间和运行时截止时间，提前规划升级，不用再靠感觉和听说了。

新 API：
GET /actions/runners/deprecations/{version}

调用示例：
curl -L -H Accept: application/vnd.github+json -H Authorization: Bearer $GITHUB_TOKEN https://api.github.com/actions/runners/deprecations/x64

返回内容：
{
runner_version: x64,
runtime_deprecates_at: 2027-03-15T00:00:00Z,
registration_deprecates_at: 2027-02-01T00:00:00Z
}

两个时间点：
runtime_deprecates_at 是这个版本的 runner 镜像哪天停止提供。
registration_deprecates_at 是这个版本哪天开始不再接受新注册。
两者通常差几周，给你足够的缓冲期迁移。

这个 API 能干什么？最直接的应用：把弃用信息接进你的升级提醒系统。

用一个简单的 GitHub Actions workflow 定期拉这个 API，runner 版本快到 registration_deprecates_at 时自动发告警：
yaml
name: Runner Version Health Check
on:
schedule:

• cron: 0 9 1
  workflow_dispatch:

jobs:
check:
runs-on: ubuntu-latest
steps:

• uses: actions/github-script@v7
  with:
  script: |
  const version = x64;
  const res = await github.rest.actions.getRunnerVersionDeprecation({
  owner: context.repo.owner,
  repo: context.repo.repo,
  version: version
  });
  const deprecatesAt = new Date(res.data.registration_deprecates_at);
  const now = new Date();
  const daysLeft = Math.ceil((deprecatesAt – now) / (1000 60 60 * 24));
  if (daysLeft <= 60) {
  console.log(Runner ${version} 将在 ${daysLeft} 天后停止注册);
  }

这样你不会在某天早上突然收到一堆 workflow 失败告警，而是提前几周就知道该升级了。

另外两个同期更新也要注意。

除了 runner 弃用 API，GitHub Actions 9 月初还同步发了两个相关更新。

第一，vulnerability-alerts 权限细粒度化。

之前 workflow 想读 Dependabot 漏洞警报，必须开 security-events: read 或者直接用 actions: read 全开。现在新增了 vulnerability-alerts 这个最小权限粒度，只读访问警报信息，不再需要宽泛的安全事件权限：
yaml
permissions:
vulnerability-alerts: read

第二，复用 workflow 的身份追溯。

复用 workflow，之前有个坑：你在主 workflow 里用 workflow_ref 拿到的是调用方的 ref，不是实际执行的那个 workflow 文件的 ref。这对于审计和安全溯源很麻烦。

现在新增了四个 job context 属性：

job.workflow_ref：定义当前 job 的 workflow 文件的完整 ref
job.workflow_sha：定义当前 job 的 workflow 文件的 commit SHA
job.workflow_repository：workflow 文件所在的仓库
job.workflow_file_path：相对于仓库根目录的文件路径

这四个值反映的是定义当前 job 的 workflow 文件，而不是调用方。只有在复用 workflow 场景下，它们和原有的 github.workflow_ref / github.workflow_sha 才有区别。

怎么用：
yaml
jobs:
audit:
runs-on: ubuntu-latest
steps:

• name: Log workflow identity
  run: |
  echo Running from: ${{ job.workflow_ref }}
  echo SHA: ${{ job.workflow_sha }}
  echo File: ${{ job.workflow_file_path }}
  echo Repo: ${{ job.workflow_repository }}

加上这三个更新，GitHub Actions 9 月的升级重点其实是可见性与控制：runner 版本生命周期可查、最小权限可配、workflow 来源可追溯。这三件事做好了，CI 的可维护性才算真正进入工程化阶段。

下一步：去你项目里搜一下 runs-on 用的是不是 ubuntu-latest，然后去 GitHub Actions 日志里翻一下当前 runner 版本，对照上面的 API 查一下它的截止时间。提前一个月处理，比突然红了再应急要舒服得多。