GitHub 五项变更：macOS 14 退役最急，11 月 2 日截止

为什么值得关注

2026 年 10 月 1 日 GitHub Changelog 集中发布五项变更，直接触及现有 CI/CD 流水线配置。

• macOS 14 runner image 于 2026 年 11 月 2 日退役，依赖该环境的项目需要在此之前完成迁移。
• Copilot CLI、Copilot App 与 Copilot SDK 支持动态工作流（Dynamic Workflows），编排逻辑可以用代码定义，替代传统 YAML 静态配置。
• 代码覆盖率上传机制调整：新分支推送到仓库后，不再因为没有开放 Pull Request 而阻断 CI。
• Scheduled code scanning 默认跳过无 push/pull request 触发的仓库，只分析活跃项目。
• Actions 保留策略统一化，checks、runs、statuses 与日志、artifact 共享同一保留时长设置。

GitHub 把编排入口从 YAML 推向代码，同时用资源回收机制压缩非活跃仓库的算力占用。

关键信息

macOS 14 runner image 退役

• 生效时间：2026 年 11 月 2 日。
• 素材说明退役期间存在临时失败机制，持续至正式下线。
• 依赖 macOS 14 的 workflow 需要在该日期前调整 runner 配置，例如把 runs-on: macos-14 改为 GitHub 当前支持的 macOS runner 版本，并核对 Xcode 与依赖兼容性。
• 从 2026 年 10 月 1 日到 11 月 2 日，迁移窗口约 32 天。
• 迁移优先级可按三个维度分档：workflow 数量（1–5 个 / 6–20 个 / 20 个以上）、跨平台测试矩阵规模（单平台 / 双平台 / 三平台以上）、Xcode 版本依赖度（无锁定 / 锁定单一版本 / 锁定多版本）。三项均落在高档的 workflow 先迁移。

Copilot 动态工作流

• Copilot CLI、Copilot App 与 Copilot SDK 支持通过代码定义编排逻辑。
• 与既有 YAML 静态配置并存，团队需要决定哪些流程改用代码定义。
• 编排逻辑以代码执行后，输入校验与权限边界需要纳入审查范围。具体控制项包括：限定 GITHUB_TOKEN 权限、secrets 按需注入、第三方 action 固定 commit SHA、对动态生成的工作流做静态审查。
• 团队需要评估把编排入口绑定到 Copilot 工具链是否符合现有工具链策略。
• 成本对比可按三项核对：代码化编排的维护工时（按人日估算）、调试链路长度（按平均定位时长估算）、与现有 YAML 并存的混合模式复杂度。三项中任意一项显著高于现有 YAML 方案时，该流程暂不迁移。

代码覆盖率上传

• 新分支推送到仓库、且没有开放 Pull Request 时，上传覆盖率不再导致 CI 失败。
• 该变更减少新分支首次推送时的误报阻断。

Scheduled code scanning

• 默认跳过无 push/pull request 触发的仓库。
• 扫描资源集中到活跃项目。

Actions retention

• 保留设置统一覆盖 checks、runs、statuses。
• 日志与 artifact 保留策略保持一致。

21ZHAO 判断

五项变更中，只有 macOS 14 退役有硬性截止日期，其余四项可按周节奏处理。GitHub 这轮变更的主线是成本控制与编排入口迁移同时推进。五项变更的处理优先级如下：

1. macOS 14 迁移：硬性截止日期 2026 年 11 月 2 日，迁移窗口约 32 天，未完成迁移的项目会在 11 月初集中遇到失败。
2. retention 核对：保留策略统一覆盖 checks、runs、statuses，需要长周期审计记录的项目要重新核对保留时长。审计记录一旦超出保留窗口即不可回溯，这一不可逆性优先于覆盖率基线的可回溯调整。
3. 覆盖率流程确认：新分支无开放 PR 时上传不再阻断 CI，团队需要确认历史质量数据基线是否变化。
4. 动态工作流评估：编排入口从 YAML 推向代码，团队需要评估哪些流水线值得改用代码定义。
5. code scanning 确认：默认跳过非活跃仓库，团队需要确认扫描覆盖范围是否符合预期。

macOS 14 退役把跨平台测试矩阵的重构压力直接压到团队身上。迁移窗口只有一个多月，未完成迁移的项目可能在 11 月初集中遇到失败。

Copilot 动态工作流把编排逻辑写进代码，灵活性提高，但代码复杂度也随之上升。YAML 静态配置的低维护性优势在这类流程里被削弱，团队需要评估哪些流水线值得改用代码定义。

覆盖率上传策略调整减少新分支误报，但历史质量数据的连续性需要团队自己确认，长期趋势分析依赖的基线可能因此变化。

Actions 保留策略统一化压缩存储成本，对需要长周期审计记录的项目，团队需要重新核对保留时长是否满足内部要求。

默认配置不再等于安全配置

下表对比五项变更的默认行为变化，团队需要主动接管以下配置：

决策清单

按处理节奏把五项变更归入三档：

• 立即处理（本周内）：盘点依赖 macOS 14 runner image 的 workflow，把 runs-on 从 macos-14 改为 GitHub 当前支持的 macOS runner 版本，优先处理跨平台测试用例。
• 本周处理：核对 Actions retention 设置，确认 checks、runs、statuses 与日志、artifact 的保留时长满足审计要求；确认 scheduled code scanning 跳过非活跃仓库后，扫描覆盖范围是否符合团队预期。
• 本月评估：检查覆盖率上传流程，确认新分支无开放 PR 时的上传行为符合团队预期；评估 Copilot 动态工作流是否值得引入，把编排逻辑封装为独立模块，保留 YAML 静态配置作为降级方案。

可复用建议

如果你只做一件事：本周内盘点依赖 macOS 14 runner image 的 workflow，把 runs-on 从 macos-14 改为 GitHub 当前支持的 macOS runner 版本。

• 把 Copilot 动态编排逻辑封装为独立模块，保留 YAML 静态配置作为降级方案。
• 检查覆盖率上传流程，确认新分支无开放 PR 时的上传行为符合团队预期。
• 核对 Actions retention 设置，确认 checks、runs、statuses 与日志、artifact 的保留时长满足审计要求。
• 确认 scheduled code scanning 跳过非活跃仓库后，扫描覆盖范围是否符合团队预期。

以上迁移优先级分档、成本对比三项核对、决策清单均为本文建议，非 GitHub 官方指引。

可延展观察

以下为待验证推测，非 GitHub 官方说明。

GitHub 在 2026 年 10 月 1 日把 scheduled code scanning 默认范围收窄到活跃仓库，同时把 Actions retention 统一到同一保留时长。若这一资源回收逻辑延续到配额层，GitHub 可能进一步收紧非活跃仓库的资源分配。可追踪指标：GitHub 后续是否发布非活跃仓库资源配额公告。

若 Copilot 动态工作流 API 开放第三方编排器集成，编排层可能形成新的竞争格局。

运行器退役过渡期，团队可提前锁定 runner 版本、监控退役公告，降低构建产物一致性与缓存失效带来的影响。

参考来源

• Dynamic workflows in Copilot CLI and the Copilot app - GitHub Changelog
• GitHub Actions: macOS 14 runner image retirement - GitHub Changelog
• Code coverage uploads no longer fail CI for new branches - GitHub Changelog
• Scheduled code scanning skips inactive repositories - GitHub Changelog
• Actions retention now covers checks, runs, and statuses - GitHub Changelog

以上来源均为 GitHub Changelog 一手链接，本文以摘要加链接形式引用，版权归 GitHub 所有。