GitHub 强制执行自托管 Runner 最低版本：代理 CI 的上线前检查
GitHub Enterprise Cloud 计划于 2026 年 9 月 25 日开始全面执行自托管 Actions runner 最低版本要求。GitHub 表示，当某个更新已发布超过 30 天，仍未升级的 runner 可能失去注册或运行支持；若发布关键安全更新，作业排队也可能暂停，直到 runner 完成升级。
对代理工程、浏览器自动化、已授权数据采集和区域验证团队来说，真正的风险是错误归因。过旧 runner 可能无法注册、一直排队或无法执行，但监控却把它记成“代理测试失败”。实际上，请求可能根本没有到达代理网关。
本次执行改变了什么
该时间表面向使用 GitHub Enterprise Cloud 的自托管 runner，包括 GitHub 公布的云端执行安排。此特定时间表不包含 GitHub Enterprise Server。
GitHub 将两个边界分开：
- 注册支持：runner 能否注册或重新注册；
- 运行支持：已连接 runner 能否接收并执行作业。
执行生效后，旧 runner 可能在任一边界失败。必须分别记录排队、注册和网络测试执行状态。只有 runner 接收作业且网络测试输出明确启动标记后，才应开始统计代理健康指标。
建立完整 runner 清单
不要只看某个仓库里显示“在线”的 runner。应覆盖组织、企业、自动扩容、临时 runner，以及未来能够创建 runner 的镜像与模板。
至少记录：
runner_group
runner_name_or_instance_id
runner_version
operating_system_and_architecture
image_or_template_digest
registration_source
last_registration_time
last_job_time
labels
network_zone
proxy_test_role
owner
upgrade_method检查安装脚本、黄金镜像、容器镜像、机器模板和灾难恢复副本。只升级正在运行的机器并不够，因为自动扩容器可能在五分钟后重新创建旧版本。
分离 runner 健康与代理健康
加入明确的生命周期标记：
- 工作流进入队列；
- runner 被分配；
- 作业启动；
- 代理测试进程启动；
- 到达代理网关；
- 认证完成；
- 目标断言完成；
- 清理完成。
只有第 5 至第 7 阶段描述代理路径。始终排队的作业不应降低代理成功率、触发出口轮换或创建提供商事故。
应为 runner 不受支持、注册被拒、作业未分配、工具启动失败和真实网络故障分别建立错误类别，避免污染采购与可靠性数据。
在截止日前找出旧版本
GitHub 提供 runner 版本信息和审计证据，包括注册事件。可以使用适用于仓库、组织或企业的视图，但要注意：注册日志只显示发生过注册的 runner，并不一定是全部在线或休眠机器的完整清单。
交叉对比三类来源：
- 控制平面中的已注册 runner 列表；
- 基础设施清单与自动扩容模板；
- 最近工作流实际执行时记录的 runner 版本。
近期没有执行作业的 runner 仍可能在故障转移时被选中，因此备用池与灾备池也必须单独测试。
升级“生产机器的工厂”
先更新创建 runner 的机制：
- 安装与启动脚本；
- VM、容器和机器镜像；
- 自动扩容启动模板；
- 离线缓存的软件包；
- runner 更新所需的网络允许列表；
- 决定 runner 何时加入标签组的健康检查。
然后替换或升级现有实例。新 runner 必须先报告受支持版本，再接收敏感代理凭据或生产网络作业。
不要为了完成升级永久扩大出站访问。应使用批准的制品来源，按组织流程验证签名或摘要，并缩小代理绕过规则。NO_PROXY 策略测试可以证明升级流量和测试流量都走在预期路径。
升级后运行代理 CI 金丝雀
在许多集群中，runner 升级同时会改变基础镜像、证书、shell 工具、浏览器、库或服务配置。全面替换前必须运行低流量金丝雀。
至少测试：
- runner 注册与作业领取；
- Action 启动及所需运行时；
- 代理密钥注入且日志不泄漏；
- 代理网关和目标域名的 DNS 行为；
- 实际使用的 HTTP 代理、HTTPS CONNECT 与 SOCKS；
- 已购买的 IPv4 与 IPv6；
- 证书与主机名验证；
- 粘性和轮换会话语义；
- 响应完整性、取消和有界重试；
- 制品上传与清理。
只对自有或明确授权的目标执行。对比旧 runner 与升级 runner 时，保持代理账号、目标、载荷和通过条件不变。
Node 24 Actions 迁移方案可帮助区分 JavaScript Action 运行时、应用运行时和代理行为。
替换期间保护凭据
临时 runner 应在通过版本与安全状态检查后，才接收短期、最小权限凭据。不能把代理密码、Cookie 或令牌固化进机器镜像。
下线旧实例时：
- 停止分配新作业；
- 等待在途作业结束，或安全取消；
- 吊销 runner 注册材料；
- 删除临时代理允许列表；
- 按策略清除本地工作目录和诊断产物；
- 确认实例不能从旧快照重新加入。
如果排错日志泄漏代理凭据，应立即轮换。删除 runner 并不会让泄漏的密钥失效。
设计仍受支持的回滚
回滚不能恢复到已不受支持的 runner 版本。应保留一个 runner 仍在支持窗口内的旧基础设施版本，或保留少量当前版本的已验证备用池。
推荐推进顺序：
- 一台非生产 runner；
- 每个网络区域一台生产金丝雀；
- 每个标签组的 10%；
- 一半集群；
- 证据稳定后全面替换。
每个阶段比较作业领取延迟、有效结果率、p95 测试耗时、重试放大和每次有效结果成本。如果响应验证下降，仅队列更快并不代表成功。
作业停止时的正确排查顺序
若执行日前后作业持续排队：
- 检查 runner 分配和版本注释；
- 确认 runner 可以注册，且符合所请求标签；
- 查看 runner 服务日志中的更新或兼容错误；
- 检查自动扩容器是否在启动旧模板；
- 只有网络测试真正启动后，才调查代理 DNS、认证、隧道和出口。
不要通过轮换住宅 IP、扩大并发或更换代理提供商来修复根本没有执行的作业。这些动作只会增加成本并破坏诊断证据。
就绪检查清单
- 已盘点全部 runner 组、备用池和自动扩容模板。
- 最新创建的 runner 报告预期的受支持版本。
- 分别监控注册支持和运行支持。
- 队列失败不会污染代理成功率。
- runner 工厂镜像与启动脚本已更新。
- 离线缓存无法重新创建旧 runner。
- 升级流量遵循批准的网络策略。
- 代理凭据在状态检查后注入，且从不固化进镜像。
- 金丝雀覆盖 DNS、认证、隧道、TLS、路线和响应完整性。
- 分别测试 IPv4、IPv6 与必要市场。
- 取消、清理与制品处理均通过。
- 回滚使用受支持的已验证 runner 版本。
- 已下线 runner 无法重新加入，注册材料已吊销。
常见问题
本次执行适用于 GitHub Enterprise Server 吗？
GitHub 公布的 9 月 25 日时间表适用于 GitHub Enterprise Cloud。公告说明 GitHub Enterprise Server 不受此特定变更影响。
安装超过 30 天的 runner 会同时停止吗？
规则与更新可用时长以及注册和运行所要求的最低版本相关。应查看当前注释和 API，而不是仅凭安装日期推断资格。
runner 显示在线就一定合规吗？
不一定。在线状态不能证明后续注册或运行资格，自动扩容器也可能继续创建旧版本。必须验证实际执行版本和源镜像。
是否应改用 GitHub 托管 runner？
这取决于网络访问、数据处理、区域要求和安全策略。托管 runner 可作为临时诊断对照，但不能替代生产 runner 架构验证。
上线期间最重要的指标是什么？
按 runner 版本与网络区域拆分的有效结果率。队列延迟、执行故障和代理路径故障必须分别统计。
合规说明
仅对自有或明确获准的系统、账号、数据与市场执行代理和数据采集检查。遵守访问控制、隐私要求、目标条款和速率限制。保护 runner 与代理凭据，只保留必要证据，不得用代理轮换隐藏违规行为。
来源说明：GitHub，《GitHub Actions: Minimum version enforcement timeline for self-hosted runners》，2026 年 6 月 12 日；2026 年 9 月 24 日复核时间表。外部研究位置仅保存在内部运营记录中。
