GitHub 自托管 Runner 将在 2026 年彻底停用旧版本

GitHub 自托管 Runner 将在 2026 年彻底停用旧版本

GitHub 明确给出最终截止日期：2026 年 9 月 25 日之后，所有运行过时版本的自托管 Runner 将无法再接收任何新的 CI/CD 任务。在此之前，从 9 月 7 日开始将进行多次 brownout 测试，具体日期为 9 月 7 日、9 日、11 日、14 日、16 日和 18 日。在这些测试日子里，Config 和 Runtime 相关的 outdated runner 既不会注册到 GitHub，也不会执行任何作业。

这种 brownout 机制设计得非常安静。工作流本身不会报错，任务只是持续停留在 Queued 状态。Runner 的日志里只会打印一句“Runner version v2.xxx.0 is deprecated and cannot receive messages”。开发者如果不主动监控，很可能直到 brownout 当天才会发现大量任务卡住。

Brownout 机制如何实际运作

Brownout 本质上是 GitHub 对自托管 Runner 版本的强制升级演练。正常情况下，Runner 每隔一段时间会向 GitHub 服务端拉取消息并注册自己。当版本被标记为 deprecated 后，在 brownout 窗口期内，服务端会直接拒绝这些旧版本的注册请求，导致 Runner 既无法上线，也无法领取任务。

这种机制不同于直接下线，它给开发者留出了观察窗口。GitHub 选择在工作日分多次进行 brownout，正是为了让团队能在真实生产环境中看到哪些机器会受影响，而非等到 2026 年 9 月 25 日真正永久禁用时才措手不及。

目前已知的受影响版本主要是 v2 系列的较老子版本。GitHub 并未一次性公布所有不再支持的具体版本号，但明确指出只要日志中出现上述 deprecated 提示，就属于即将被淘汰的范畴。

国内开发者面临的实际影响

对中国团队来说，这次 brownout 和最终禁用带来的影响比海外团队更直接。很多企业出于合规、数据不出境或网络稳定考虑，长期使用自托管 Runner 部署在阿里云、腾讯云或本地机房。这些 Runner 往往几年没有升级，版本停留在 v2.300 甚至更早。

一旦 brownout 发生，正在跑的流水线不会中断，但新触发的 PR 检查、定时构建、部署任务都会卡在队列里。国内很多 CI 流程和业务发布节奏强绑定，卡住几个小时就可能导致版本发布延误、客户投诉或线上事故。

此外，国内网络环境本身对 GitHub 的连接就不如海外稳定。Runner 注册失败后，日志排查也需要额外翻墙或使用企业代理，进一步增加运维成本。如果团队同时管理几十台甚至上百台 Runner，手动一台台登录检查版本几乎不可能。

如何快速定位受影响的 Runner

最直接的办法是利用 GitHub 提供的 API 批量查询所有自托管 Runner 的版本信息。可以使用以下命令行方式快速扫描：

1
2
3

gh api -H "Accept: application/vnd.github+json" \
  /repos/{owner}/{repo}/actions/runners \
  --paginate | jq '.runners[] | select(.status == "online") | {name, os, status, version}'

或者针对企业账号级别查询所有组织的 Runner。重点关注 version 字段中以 v2. 开头且小于当前最新稳定版的记录。

除了 API，还可以直接在 Runner 机器上运行 runner --version 命令，或者查看日志文件中的版本声明。推荐的做法是把这一步做成定期脚本，每天或每周自动生成一份“即将被 brownout 的 Runner 清单”，并推送到企业微信或钉钉。

对于大规模部署，建议结合 Ansible 或 Terraform 管理 Runner 镜像，确保所有新部署的机器默认使用最新版 runner。同时对老机器打上标签，在 GitHub Actions workflow 中通过 runs-on 明确排除已知过时标签。

升级 Runner 的具体操作步骤

升级过程并不复杂，但需要注意停机窗口。官方推荐方式是停止当前 runner 服务，下载最新版 runner 包，解压覆盖，然后用相同标签重新注册。

关键点在于注册时使用的 PAT 权限必须具备 admin:org 或 repo 范围。升级完成后，建议立即触发一次测试 workflow，确认新版本能正常领取任务。

对于容器化部署的 Runner（例如运行在 Kubernetes 中的 runner），需要更新对应的 Docker image tag，并重新 rollout deployment。很多团队把 runner 做成 Helm chart，升级时只改 values.yaml 中的 version 字段即可。

GitHub 之外的替代 CI 方案

如果自托管 Runner 的维护成本已经过高，或者担心未来 GitHub 继续收紧策略，可以考虑以下几种替代方案。

首先是完全托管的云 CI 服务。GitLab CI、CircleCI、Jenkins Cloud、Travis CI 以及国内的腾讯工蜂、阿里云云效、华为云 DevCloud 都提供成熟的托管 Runner 能力。它们在国内节点延迟更低，且无需自己维护底层虚拟机。

其次是自建 GitLab 实例并使用其内置的 GitLab Runner。GitLab Runner 的配置语法和 GitHub Actions 有一定差异，但迁移成本可控。很多团队选择同时保留 GitHub 用于代码托管，把 CI 部分全部切到自有 GitLab 实例上。

另一个值得关注的方向是基于 Kubernetes 的通用 CI 引擎，例如 Tekton 或 Argo Workflows。它们不绑定任何代码托管平台，Runner 完全由自己掌控，版本升级策略也更灵活。国内不少大型互联网公司已经在内部落地了基于 Tekton 的统一 CI 平台。

最后，如果项目规模不大，也可以考虑直接使用 GitHub 官方托管的 runner（ubuntu-latest 等），结合自建缓存服务（例如自托管的 GitHub Actions Cache 服务）来平衡成本和合规需求。

需要立刻采取的行动清单

  1. 本周内通过 API 或脚本盘点所有自托管 Runner 的版本分布；
  2. 对版本低于当前最新稳定版的机器制定升级计划，最迟在 9 月 18 日最后一次 brownout 前完成；
  3. 将 Runner 版本检查纳入日常监控，避免未来再次出现大面积过期；
  4. 评估是否需要将部分或全部 CI 迁移到其他平台，提前进行小规模 PoC；
  5. 通知团队成员 brownout 日期，避免在测试当天出现大面积任务积压。

这次 brownout 表面上看只是版本升级提醒，实质上是 GitHub 对自托管基础设施控制权的进一步收紧。国内开发者越早完成排查和升级，受到的实际业务冲击就越小。

（全文约 2150 字）

参考来源