导语：
截至 2026 年 3 月 17 日，后端平台团队面对的一个典型误解是：GitHub 暂停了 self-hosted runner 最低版本强制门槛，就等于这轮平台升级压力没了。事实恰恰相反。GitHub 在 3 月 13 日发布 Self-hosted runner minimum version enforcement paused，并在 3 月 17 日补充说明：暂停只影响注册/配置时的最低版本限制，不代表已经注册的老 runner 可以长期继续使用；同时，落后于最新发布超过 30 天的 runner 仍会按照标准弃用流程被拒绝执行工作流。
再叠加 Kubernetes v1.35.3 已经发布，这意味着平台团队依然处在一个需要联合治理的窗口，只是规则更细，不是压力更小。
1. 为什么“暂停 enforcement”很容易被误读
- 因为很多团队只看标题，不看补充说明。
- 因为平台注册和实际执行是两套不同约束。
- 因为 runner、镜像、workflow、集群补丁往往被不同人维护，容易出现责任空档。
2. 当前更正确的理解方式
- runner 最低版本问题没有消失，只是节奏调整。
- 已注册老 runner 的长期风险依然存在，尤其是关闭自动更新的环境。
- 平台团队仍需要把 runner 升级、workflow 兼容和集群补丁放在一起看。
3. 推荐执行流程
- 先拉出 self-hosted runner 全量台账。
- 标记所有禁用自动更新或由 ARC 管理的节点。
- 检查 runner 版本与最新支持窗口的差距。
- 统一验证 workflow 对当前 Node 运行时和 action 的兼容性。
- 与 Kubernetes 补丁窗口一起做候选环境回放。
- 对关键流水线建立备用 runner 池和回退脚本。
4. 建议重点检查的点
- 注册版本与执行版本是否被混淆。
- 自定义 action 是否还依赖老 Node 版本。
- 老 runner 是否隐藏在低频任务或特殊网络区域。
- 平台补丁和 runner 替换是否会叠加影响缓存、构建时长或网络行为。
5. 指标建议
- 老旧 runner 清理率。
- 核心 workflow 成功率。
- 队列等待时长与构建时长变化。
- 平台升级后的回滚成功率。
- 版本台账完整率。
6. 结语
3 月 17 日这次规则说明的真正价值，是提醒平台团队不要把“节奏延后”误解成“问题消失”。后端平台最怕的从来不是升级本身，而是误判升级窗口。
参考资料
- GitHub Changelog: Self-hosted runner minimum version enforcement paused（2026-03-13，3/17 更新说明）
https://github.blog/changelog/2026-03-13-self-hosted-runner-minimum-version-enforcement-paused - Kubernetes: v1.35.3 is now available（2026-03-11）
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md#v1353 - GitHub Changelog: Optionally skip approval for Copilot coding agent Actions workflows（2026-03-13）
https://github.blog/changelog/2026-03-13-optionally-skip-approval-for-copilot-coding-agent-actions-workflows
