AI 编码使 CI 成为瓶颈，因此我们重新设计了我们的编码以跟上

今年早些时候，我打开 Linear 发现我们的 CTO Tuomas 给我布置了一个问题，标题为“CI 成本很高”。当我这样做的时候，他也希望我让 CI 更快。代理使代码交付速度呈指数级加快，但验证这些更改的速度却没有完全跟上。每个 PR 仍然需要经过 CI，因此随着开发的加速，CI 成为瓶颈，推高基础设施成本，让开发人员和代理商等待反馈的时间更长。为了让 CI 在 Linear 中具有更高的性能，我们优化了 PR 等待 CI 的时间以及它消耗的运行时间。尽管我们的测试套件自今年年初以来几乎翻了两番，但我们将拉取请求等待时间从 6 分钟多减少到 5 分钟多，同时将每次测试的运行时间大约减少了一半。这是以一月第一周为索引的测试套件性能。当我们添加测试分片时，跟踪每个测试的机器时间的白线会达到峰值，这会缩短等待时间并花费更多的机器时间，并且在结账停滞问题期间也会再次出现。 总的来说，我们通过四种方式改进了 CI： 升级基础设施和工具 优化控制其他工作的作业 减少重复设置 提高测试执行效率 Linear 的代码库主要是 TypeScript，但其中许多优化适用于跨语言和工具链。升级的基础设施和工具 ⁠ 我们最早的一些成果几乎不需要 CI 本身的优化。将我们的工作负载从 GitHub Actions 转移到具有更快 CPU、更高性能存储和更好缓存基础设施的第三方运行程序，使我们能够在更快的机器上运行相同的管道。通过对切换前后两天的同类比较，作业的平均运行速度提高了 34%，某些工作负载（例如 tsc）下降了 52%。另外，我们的工具链现代化也取得了回报。切换到 tsgo（原生 TypeScript 编译器）后，每周 tsc 检查的中位数减少了 73%，足以完全消除类型检查的瓶颈。没有类型检查器的 Lint ⁠ Linting 是另一个早期目标。我们的一些自定义 lint 规则依赖于 TypeScript 类型信息，要么强制执行限制，要么应用自动修复。这意味着每次 lint 运行都必须在评估这些规则之前构建完整的类型图，这使得 linting 成为我们内存最密集的 CI 作业之一。我们重写了规则，以在抽象语法树上使用静态分析，识别类似函数的构造和没有类型信息的保护模式。这让 ESLint 完全放弃了 TypeScript，将 API lint 时间减少了 68%，将整个存储库 lint 时间减少了 55%。内存使用量也大幅下降。消除对类型信息的依赖也使我们后来转向 Oxlint 变得更加容易，因为纯粹基于语法操作的规则很容易移植。 Oxlint 本身减少了 CI 运行者花费在 linting 上的时间。优化影响其他工作的工作 ⁠ 随着底层基础设施和个人检查运行得更快，我们缩小范围，将 CI 视为一个系统。这让我们注意到那些排在其他一切前面的小工作。每次运行都首先检查 PR 触及的路径以及相同输入的这些测试是否已通过。我们在工作级别进行这些检查，因此跳过的工作永远不会保留跑步者，但这也将它们直接置于关键路径上。八个 API 测试分片在完成之前都无法启动，因此即使是很小的延迟也变得异常重要。仅获取每个作业需要的内容 ⁠ 我们的一些工作流程以变更检测作业开始，该作业决定接下来运行的内容；例如，它检查 diff 是否包含数据库迁移并输出用于安排相关数据库 CI 检查的信号。这些作业正在检查完整的工作树，即使它们只需要其中的一小部分。我们限制了获取深度，这些门中最慢的时间从 94 秒减少到 20 秒，并从不需要工作树的作业中完全删除了签出，将花费在这些任务上的时间从 27 秒减少到 7 秒。对于提交推送和合并队列事件，我们确实必须比较路径，我们发现历史记录有限的稀疏、无 blob 签出就足够了，又节省了 11 秒。变化检测作业的中位持续时间从 26 秒下降到 8 秒，p90 从 31 秒下降到 12 秒，最慢的运行时间从 138 秒下降到 37 秒。让结帐更具弹性 ⁠ 在我们更换底层运行器基础设施后，我们注意到工作中的结帐时间（使用 actions/checkout ）变得更长，有时会挂起。由于第三方运行者位于 GitHub 网络之外，因此他们依赖直接 IP 链接来访问 GitHub。提供商将挂起追溯到该链接上的间歇性降级。我们的几个工作流程都是从结帐开始的，因此停滞的获取可能会延迟整个 CI 运行。为了适应网络不稳定，我们用复合操作替换了操作/结帐