20260828 当 GitHub Actions 配额耗尽：我如何用 gh-signoff 把 iOS CI 搬回本地
内容提要
作者因GitHub Actions配额耗尽，将iOS测试从远端CI迁移至本地Mac执行，并用gh-signoff将结果发布为GitHub Commit Status，PR仍显示绿/红状态。此方案拆分测试执行与结果展示，保留可见性，但依赖本地环境，适合边界清晰项目，非远端CI的完全替代。
延伸解读
拆分CI：执行与展示解耦
作者将CI拆为本地执行与GitHub展示两部分，用gh-signoff把本地结果发布为Commit Status。这种模式保留了PR上的红绿状态，但实际测试在开发机运行。它适合边界清晰、环境可控的项目，但并非远端CI的完全替代，团队需信任本地机器与脚本。
配额耗尽的信号失真问题
当GitHub Actions配额耗尽，job无法启动，PR显示红色失败，但原因并非代码问题，导致CI信号失真。作者指出，此时CI最重要的能力——用红色表示代码有问题——已失效。这提醒开发者，CI的可靠性不仅取决于测试本身，还取决于执行环境的可用性。
本地CI的边界与风险
本地CI并非没有风险：共享Simulator、后台任务和环境漂移都可能造成假红。作者通过固定工具版本、检查gh-signoff版本、确保干净工作区等方式降低风险，但仍需持续管理Xcode、Simulator runtime等。此外，本地运行缺乏集中式日志和artifact托管，且无法强制合并门禁。
适用场景与替代方案
作者认为本地CI加gh-signoff适合边界清晰、环境可控的项目，如个人或小团队项目。若项目依赖多平台矩阵、严格供应链隔离、集中审计或大规模并行测试，远端CI仍更合适。此方案提供了一种在成本与反馈质量间权衡的思路，但并非通用解决方案。
Q&A
GitHub Actions 配额耗尽后，作者是如何处理 iOS CI 的？
作者没有关闭 CI，而是将测试执行搬回本地 Mac，并使用 gh-signoff 将本地检查结果发布为 GitHub Commit Status，这样 PR 仍然会显示绿色或红色的 signoff，但实际运行测试的机器变成了开发机。
gh-signoff 是什么？它有什么作用？
gh-signoff 是 Basecamp 开源的 GitHub CLI 扩展，它不负责运行测试，而是将本地测试结果发布为 GitHub Commit Status，支持通过 --url 添加详情链接，并支持显式发布失败状态。
作者为什么选择使用 gh-signoff 而不是直接关闭 GitHub Actions？
因为直接关闭 GitHub Actions 会丢失关键能力：其他人打开 PR 时无法知道某个精确 commit 是否经过完整检查。gh-signoff 可以将本地检查结果绑定到已推送的精确 SHA，并在 PR 上显示状态，保留可见性。
FoodPhotos 项目的本地签核流程有哪些关键步骤？
流程由 scripts/signoff-local-ci.sh 编排，包括准备签核、运行质量检查、UI 测试、按需 E2E 测试，最后通过 gh signoff 发布成功状态；任何步骤失败都会通过 ERR trap 调用 gh signoff fail 发布失败状态。
作者为什么选择单一的 signoff 聚合状态而不是多个 context？
因为 FoodPhotos 只有一个本地交付入口，所有检查必须在同一次执行中全部满足。拆成多个 context 会增加部分状态过期和遗漏签核的可能性，却没有带来足够收益。
本地 CI 方案有哪些局限性？
局限性包括：验证者变成开发者自己的机器，需要信任；没有集中式日志和 artifact 托管；绿色状态可能不是强制合并门禁（取决于仓库配置）；本地环境仍会漂移，需要持续管理。
作者认为本地 CI 加 gh-signoff 适合什么样的项目？
适合边界清晰、环境可控的项目，例如对隔离构建、合规审计要求不高的项目。如果项目依赖多平台矩阵、严格供应链隔离、集中审计、自动部署或大规模并行测试，远端 CI 更合适。
作者在迁移过程中遇到了什么问题？
第一次正式运行时，由于另一个 worktree 同时操作相同的 Simulator，导致视觉检查失败，本地脚本正确发布了红色 signoff。等待任务结束后，独占 Simulator 才通过。这暴露了本地资源协调的边界。
