CI 效率与 Runner 容量¶

审计日期：2026年9月5日。未更改付费容量或提供商配置。

测量与变更¶

三次近期成功的 PR 运行共使用了 54.6–64.9 个聚合 runner 分钟： 33998366568、 33998220287 和 33998181502。 这些是活跃任务时长的总和，不包括已跳过的任务；它们不是计费分钟数或排队时间。这个小样本并非历史平均值。

• 将 E2E 路由整合到现有的代码路径检测器中。被移除的检测器占用 20–22 秒，并且每个非草稿代码 PR 都需要额外的 runner 分配和完整历史检出。原有的路由命令保持不变，包括 SSH 和原生 IME 选择；实际的 E2E 结果仍为参考性质。路由脚本错误现在会导致必需的代码路径检测器失败。
• 对仅限 PR 的 Debian/RPM 产物使用 gzip 压缩。两个采样的 Linux 打包任务整体分别耗时 8m10s 和 8m19s；其中一个在 electron-builder 中花费了 3m47s。其默认的 Debian/RPM 压缩格式为 xz。PR 产物在同一 runner 上检查，因此下载大小没有任何益处。保留所有 AppImage、Debian、RPM、payload、launcher 和 shutdown 检查。发布版压缩格式不变。33999422341 中的托管验证将包构建步骤缩短至 2m13s，整个 Linux 任务缩短至 6m17s，所有现有检查均通过。这是一个小的观测样本。
• 取消已被取代的 Mobile Checks 和 Skill 更新往返 PR 运行。skill 矩阵有 13 个任务。保留不取消的 main/merge-group skill 运行，每个事件使用独立的并发组。
• 在 Mobile Checks 中复用现有的无脚本根依赖 action，包括以根锁文件和移动端锁文件为键的 pnpm 缓存。由于移动端类型导入根依赖，根安装仍然是必需的。

该仓库已有八个单元测试分片、按路径划分的平台检查、原生缓存、一个共享的 E2E 构建、PR 取消、增量 TypeScript 缓存以及变更规格 E2E 路由。增加分片会增加设置工作和并发的 runner 需求。在未比较同一提交上的关键路径时间和聚合任务时间之前，不要调整分片数量。

后续节省¶

• 将每小时 main/release 新鲜度检查移至五分钟的 Ubuntu 预检任务，无需检出。在未变更的运行 33986205749 中，Blacksmith macOS 在跳过之前被占用了 40 秒，其中包括 30 秒的检出。新的任务级门控避免了该 Mac 分配。实际构建会多一次 Ubuntu 调度跳转；将 Mac 检出和下游 Windows 身份固定到预检所检查的 SHA。
• 对于已验证的 Linux Node-runtime 缓存命中，避免全局 npm install -g node-gyp。在跳过之前使用现有的原生模块加载/来源检查；未命中、损坏的插件和 Electron 任务仍然安装重建工具链。action 文件参与缓存键，因此此次推出会创建一次全新的原生缓存。目前尚未声称测得的热缓存秒数。

Runner 建议¶

该仓库是公开的，已通过 GitHub API 验证。标准的 GitHub 托管 Linux、Windows 和 macOS runner 对公开仓库提供免费计算分钟数。队列压力和第三方提供商配额仍然重要；产物存储和更大规格的 runner 有单独的计费规则。请参阅 GitHub Actions 计费。

1. 保持标准的 GitHub 托管 runner 作为默认。在付费购买更多容量之前，请向 GitHub Support 申请更高的并发任务限制。文档化的标准限制取决于账户套餐（Free：总计 20/5 个 macOS；Team：60/5；Enterprise：500/50），增加需经批准。实际账户权限未经验证。请参阅 限制。
2. 如果 macOS 是优先事项，请将现有的 Blacksmith 配额保留给 macOS。Blacksmith 文档规定每个组织 3,000 分钟的免费 x64 2-vCPU 等效分钟数；一个 6-vCPU Mac 分钟消耗 20 个等效分钟，如果使用整个免费池，则为 150 个实际 Mac 分钟。云工作流也使用 Blacksmith Linux。将 Linux 迁移到托管的 GitHub 可节省共享配额，但不一定能释放 Mac 硬件容量。账户特定的合同和使用情况未经检查。请参阅 Blacksmith runners。
3. 将 Ubicloud 视为可选的小型 Linux 溢出试用。其文档化的 $2.50 月度信用额度可购买 1,250 个高级 2-vCPU 分钟（$0.002/分钟），或 2,000 个标准 2-vCPU 分钟（$0.00125/分钟）。新账户默认使用高级版并要求绑定信用卡。未验证有可执行的硬性支出上限，因此更改 runner 标签无法保证不超支。一个 PR 大约 55–65 个 runner 分钟也清楚地表明，相对于仓库活动量，这个池子有多小（硬件速度不同）。请参阅 定价 和 设置。

一个有界 Ubicloud 候选方案¶

performance-contracts.yml 的 Linux 部分在 33994756657 中耗时 48 秒。其每日调度和 20 分钟超时使其成为一个小型候选方案：31 次常规调度尝试最多允许 620 个任务运行分钟，这不包括 runner 启动/清理计费。Ubicloud 2-vCPU 硬件上的实际耗时仍需测量；GitHub 上的耗时仅作为规模参考。

如果之后启用，仅将计划中的 Linux 任务的第一次尝试路由到 Ubicloud；将 PR、手动调度、重跑以及 macOS/Windows 保留在 GitHub 上。这样可以避免将配额花费在不可预测的 PR 量上。在启用之前检查其他账户使用情况和可用信用额度；工作流超时不是账户级别的计费上限。9月5日，该组织的 GitHub App 安装列表包含 Blacksmith，但没有 Ubicloud 安装，因此此后续方案将 runner 选择保留在 GitHub 上，而不是将工作排队到未配置的标签上。

同时运行编程代理的机器¶

不要直接将持有凭证的主机注册为公共 PR 运行器。PR 可以执行任意构建/测试代码，而持久化主机可能让这些代码访问本地凭证或影响后续任务。当 Docker 暴露主机主目录、Docker 套接字、SSH 代理或办公网络时，仅靠 Docker 无法提供足够的隔离。

一个无需新硬件的可行实验方案是每个任务使用一次性虚拟机，最好在专用的备用机器上，搭配即时（JIT）单任务运行器，不共享主目录/钥匙串/SSH 代理或主机挂载，限制网络访问，并设置能为编程代理留出余量的 CPU/RAM 限制。每个任务结束后销毁虚拟机；临时运行器注册本身并不会清理机器。先从受信任分支/手动工作负载开始，并将公共 fork PR 保留在托管运行器上。即使机器已经自备，预配和持续修补也是实际运维成本。请参阅 GitHub 的自托管运行器安全指南。

发布等待¶

最新一次抽样的成功 Windows 发布在签名等待/下载步骤中耗用了 21m56s 任务中的 13m59s。同一次发布中，一个 Ubuntu 任务在轮询隔离 Mac 构建时被占用了 11m38s。与较小的检出时间节省相比，这些是更显著的占用优化机会，尤其是在审批需要数小时的情况下。

在不占用运行器的情况下进行 Windows 签名描述了一种分阶段、同次运行的设计、所需的受保护环境以及预演标准。目前不存在回调集成或受保护的 Windows 签名环境。环境门控设计会在每次 SignPath 审批后增加一次 GitHub 审批，并改变当前自动内部签名超时回退机制；这些属于明确的发布策略决策，因此本 PR 不改变生产签名行为。

第二次审计和托管试用¶

• 在抽样的 39 小时窗口内，Cloud Verify 运行了 100 次（84 次 PR 和 16 次推送运行）。将其四个 Ubuntu 22.04 任务从 Blacksmith 迁移到标准托管 Ubuntu 22.04，保留 Postgres、密钥扫描、构建、测试和 Terraform 验证。基线 34001538145 中安全/测试/构建/Terraform 分别耗时 64/72/26/19 秒。这可以节省共享服务商配额；必须检查托管延迟。
• 为 13 任务技能往返矩阵保留完整标签历史，但惰性获取 blob。只有两个历史 SKILL.md 文件被物化。基线 33999994876 每次检出花费 42–84 秒，累计约 14 个运行器分钟。托管试用必须验证所有三个操作系统上的历史 blob 获取。
• 为原生 IME CI 使用现有的 Electron/原生依赖缓存。保留确定性边界测试和真实 IBus 测试。为 Terminal Perf 和发布黄金/证据通道添加 pnpm 存储缓存；保留其原始安装步骤，因为手动选择的较旧 refs 可能不包含共享操作。
• 仅对发送到 SignPath 的已压缩 NSIS 安装程序禁用 ZIP 重新压缩。安装程序内容、发布压缩和签名保持不变。
• 在三个渲染器测试文件中使用作用域内的模拟定时器提前现有的布局与启动截止时间。全部 34 个测试在本地测试执行中用时 62 毫秒通过，而抽样托管基线为 65.182 秒。导入和转换仍占调用时间的主导；这并不声称 PR 端到端时间节省相同。

八个单元测试分片已经具有均衡的 260–296 秒抽样时长。减少分片或移除测试隔离缺乏净收益的证据。真实子进程测试有意覆盖生命周期行为并保留真实时钟。在早期 12 路超时后，14 路 E2E 拆分保留了余量。降低覆盖率或调度频率不在本次效率优化范围内。为仅需七秒的文档安装增加缓存复杂性不太可能回本。跨模式复用发布构建可能导致遥测标识和原生平台工件不一致的风险。

Terminal Perf 的基线 33955846492 在测量终端性能之前，在其共享页面夹具中等待 workspaceSessionReady 超时 30 秒而失败。应将托管试用与该已知失败进行比较，而不是将其归因于依赖缓存更改。

第二次审计的托管试用：

• Cloud Verify 34002295216 在标准托管 Ubuntu 上通过了全部四个任务：安全 57 秒、测试 102 秒、构建 35 秒、Terraform 19 秒。测试通道比 Blacksmith 样本慢 30 秒；保留这适度的延迟权衡以节省共享配额。
• Skill matrix 34002295221 全部 13 个分支均通过，包括历史 blob 物化。检出时间：Linux 为 18–20 秒，macOS 为 39–45 秒，Windows 为 49–58 秒，而先前各平台范围为 42–84 秒。这些是观测样本。
• Native IME 34002299594 确定性检查和真实 IBus 检查均通过。共享依赖设置耗时 29 秒，而抽样基线中旧的安装/工具链步骤为 35 秒。
• 仅涉及 Native IME 的源码/规格更改不再分配可复用的 E2E 构建、缓存和消费任务，仅为了过滤出原生规格。单独的原生工作流仍会运行；仅 SSH 和混合规格列表仍会分配可复用工作流。路由契约覆盖了这些情况。
• Hourly 34001816449 演练了新的五秒预检并成功发布了 macOS。Windows 后续任务在其未变更的输入审查获取中失败，因为远程 refs 在其大小写不敏感的文件系统上仅大小写不同。请求的 SHA 是正确的；这还不能验证未变更主干跳过逻辑。

将每日 Mac 新鲜度检查移动的预期价值低于每小时检查：每天只有一次潜在的闲置分配，并且活跃开发通常需要该构建。在跳过频率足以证明其合理性之前，推迟对发布图的另一次更改。剩余具有实质意义的发布占用机会，是已单独记录的异步签名策略决策。