⚙️ 工程
在主分支中捕捉 flakesCatch Flakes On Main
本文提出一种机械式习惯：在持续集成流程中主动检测并修复 flaky 测试。flaky 测试指在相同代码下结果不稳定的测试用例，严重影响 CI 可靠性。作者建议通过定期运行主分支上的关键测试套件，自动识别波动行为。一旦发现 flakiness，立即触发修复机制，避免问题进入生产环境。该方法显著提升了构建稳定性与团队对 CI 的信任度。
今天的小机械习惯：
在使用“非火箭科学规则”/合并队列时，继续在 main 分支上冗余地运行完整的测试套件。维护一份易于访问的 recent main 失败列表——这些就是需要根除的 flaky 测试。
示例请参见 https://devhub.tigerbeetle.com 上的“Flakes”链接。
Flaky 测试是指偶尔失败的测试，比如一千次运行中失败一次。这可能是由于真实 bug（例如对调度机制的假设通常成立）或底层基础设施的不稳定性导致（例如无法从 GitHub 下载发布版本，或在 Windows 上无法删除文件夹）。无论哪种情况，flaky 测试都是巨大的生产力损耗——随着测试套件的规模和复杂性增长，越来越多的 CI 运行会因虚假原因失败，即使每个单独的测试几乎总是通过。
处理 flaky 测试很棘手——如果你正在尝试合并 PR，而 CI 因明显的 flake 失败，那么重新运行测试套件的诱惑力极大，尤其是当背后存在对基础设施稳定性的普遍不满时。
如果你有心去“压平”（squash）这些 flaky 测试，那么你的 PR 就会为了气你而变绿！而且基于他人的 PR 工作，首先必须将 flaky 失败与真实失败区分开来。
这就是合并队列强大的原因：如果保证 main 分支上的每个提交都通过了测试，那么根据定义，main 上的每次失败都是 flake。将所有此类失败收集到一个列表中，可以压缩时间、优先处理最影响稳定性的来源，并揭示失败之间的关联。
需要完整排版与评论请前往来源站点阅读。