GitHub Actions macOS 14 Runner 退役前，怎么查全遗留工作流？2026 清单

症状： GitHub Actions macOS 14 Runner 已公告于 2026 年 11 月 2 日退役，旧标签任务届时会受影响。GitHub 官方退役公告列出的标签包括 macos-14、macos-14-large 和 macos-14-xlarge。
最快解法： 先盘点组织、仓库、复用工作流和实际运行记录，再按工作负载验证迁移；只搜索默认分支的 YAML，不足以证明遗留依赖已找全。

这篇适合 GitHub 组织管理员核查各仓库的旧 Runner 标签依赖。
如果你负责 CI 平台，需要同时检查复用工作流、动态配置与运行历史。
如果你负责研发或发布，则要为构建、测试、签名和发布任务留存迁移验收证据。

先按什么范围衡量遗留标签覆盖率？

先定边界，再开始搜代码。若仓库清单不完整，搜索结果再干净，也只证明你查过的范围里没有命中。

GitHub Actions 的 runs-on 可以是字符串、变量、标签数组，也可以由矩阵或表达式参与生成；因此，静态搜索旧标签是必要步骤，但它不是完整审计。工作流语法文档说明了 runs-on 与矩阵配置的写法；Runner 选择文档也列出 Runner 标签和变量等配置形式。

先建立扫描对象清单：纳入组织内所有相关仓库，标出默认分支、仍在维护的分支、归档状态、仓库负责人，以及扫描时无法访问的对象。对无法扫描的仓库或分支，登记原因和补查责任人；不要把“暂时打不开”记成“没有依赖”。

按标签逐一搜索官方公告列出的 macos-14、macos-14-large、macos-14-xlarge，避免只搜不带 large、xlarge 后缀的基础标签。公告也给出了退役前的临时 brownout 时段及替代标签建议；这些信息应与实际项目验证结果分开记录。

⚠️ 一次搜索只代表一次搜索。仓库范围、分支范围和权限范围没有证据时，不能把搜索命中数当作组织覆盖率。

配置源头与消费位置，怎样一起查？

把“标签写在哪”和“谁最终使用它”拆开登记。否则你可能只改了调用方参数，却漏掉复用工作流中的默认值；也可能改了模板，却没有发现旧调用链仍引用旧配置。

第一步：检查仓库中的工作流和共享模板

对每个纳入范围的仓库，扫描工作流文件、模板、脚本和生成配置。搜索三种退役标签的原文，同时搜索配置变量名与赋值来源。发现命中后，登记仓库路径、工作流名称、分支、行号、标签来源和负责人。

第二步：沿复用工作流调用链向下追

复用工作流既可能在当前仓库，也可能位于其他仓库；调用关系还可以嵌套。复用工作流文档说明了调用方式、访问条件和嵌套限制。你需要同时检查调用方的 uses、with 参数和被调用工作流的 runs-on，不要只在调用方仓库里搜标签。

若标签来自 vars、inputs、矩阵或 ${{ ... }} 表达式，记录变量来源、取值条件和最终 Runner 标签。GitHub 的上下文与表达式文档说明上下文值会随运行条件变化；表达式文档可用来核对表达式的求值方式。

第三步：用运行记录核对静态结果

静态配置不一定能还原每次运行实际调用的文件和任务。通过 Actions 页面或工作流运行 REST API，逐项记录工作流名称、事件类型、分支、运行时间和结论；对于复用工作流，还应确认运行记录关联的工作流文件。

把定时任务、手动触发任务和特定分支任务单独标出。工作流近期没有失败，不代表它不受退役影响：它可能从未在你抽查的时间段运行，也可能只在发布或紧急操作时被触发。schedule 的配置、默认分支和事件条件会影响实际运行，因此要用配置与运行证据一起判断，而不是用“最近没报错”结案。

怎么把扫描结果变成迁移验收证据？

把命中记录从“待改标签”变为可复核的工作项。建议每条至少有仓库路径、工作流名称、事件、标签来源、实际运行证据、任务负责人和处理状态。不同团队可使用自有表格或工单系统；关键是每个结论能回到具体文件和运行记录。

按业务影响分层，不要把普通 PR 检查与发布阻断任务混在一起。PR 验证失败可能影响合并节奏；签名、归档和发布任务失败则可能阻断交付。记录工具链固定要求、签名依赖和未解决兼容性，迁移选项要经真实项目验证，不能从官方建议直接推断你项目的兼容性、性能或队列表现。

迁移验收勾选清单

• [ ] 已导出组织内相关仓库清单，并记录已归档、未访问、无权限和待补查对象。
• [ ] 已分别扫描 macos-14、macos-14-large、macos-14-xlarge，并保存命中的仓库路径和工作流位置。
• [ ] 已检查复用工作流、调用参数、嵌套调用、矩阵、上下文变量和生成配置。
• [ ] 已将静态扫描与运行记录交叉核对，并标记定时、手动和特定分支任务。
• [ ] 已为每个受影响工作负载指定负责人、业务影响等级和迁移方案。
• [ ] 已在真实项目流水线验证构建、测试，以及适用的签名和发布步骤。
• [ ] 已保存迁移前后配置差异、任务结果、未通过项和批准的临时例外。
• [ ] 所有例外均有批准人、复查时间和关闭条件；无责任人的阻断项仍保持未关闭。

✅ 如果运行证据与配置文件不一致，先追查实际执行的调用链，再改配置；不要仅凭一次成功运行就关闭其他未验证分支或发布任务。

盘点发现未关闭项时，怎样决定是否放行？

放行依据应是覆盖范围、运行证据和未关闭风险，而不是“改过标签”这一动作本身。GitHub 公告给出标签替代建议，但企业流水线仍要验证目标系统版本、Xcode 和依赖、构建测试、签名与归档等实际步骤。

若官方公告或镜像信息更新，重新核对退役标签、brownout 计划和替代建议；不要沿用旧清单中的结论。

最后更新于 2026 年 10 月 8 日；退役日期、受影响标签、brownout 与替代标签核实自 GitHub 官方退役公告及 Runner Images 信息。公告列出的退役日期为 2026 年 11 月 2 日；实际仓库覆盖率与迁移结果必须由你自己的扫描和流水线运行记录确认。

如果现有托管 Runner 方案让你难以固定迁移窗口、控制镜像变化，或为签名发布任务安排独立环境，可进一步评估自有 Mac 节点；但自购会带来硬件采购、维护和闲置成本，远程租赁也不适合需要特定物理接口或长期满载且已有成熟自管能力的团队。先看企业 Mac CI 使用场景，再按当前公布的套餐与计费周期核算是否适合；只有确认环境、权限和交付条件匹配后，才把特定工作负载交给 KVMFLUX。

延伸阅读

• GitHub Actions macOS Runner 自动扩容：企业部署与容量验收
• 自托管 Runner 部署：远程 Mac 注册、安全加固与运维检查
• Xcode Cloud 与自建 Mac CI：迁移任务如何划分与验收

常见问题 FAQ