Rust项目Miri从Bors迁移至GitHub合并队列的技术决策

在Rust语言的Miri项目开发过程中，团队近期完成了一项重要的基础设施变更：将代码合并系统从传统的Bors迁移到了GitHub原生提供的合并队列(Merge Queue)功能。这一技术决策背后有着多方面的考量和权衡。

背景与动机

Miri作为Rust项目的重要组成部分，长期以来使用Bors作为其代码合并系统。Bors是一个专门为开源项目设计的合并机器人，它通过创建临时合并提交来确保多个PR的集成测试能够通过。然而，随着时间推移，团队发现Bors存在一些稳定性问题，特别是在处理复杂依赖关系时偶尔会出现故障。

GitHub近期推出的合并队列功能为项目提供了另一种选择。该功能允许PR在通过初步CI检查后被放入一个队列，系统会按顺序自动合并这些PR，同时确保每次合并后主分支仍然保持健康状态。这一机制与Bors的核心功能相似，但作为GitHub原生功能，其集成度和维护性更佳。

技术优势分析

迁移到GitHub合并队列带来了几个显著优势：

1. 简化基础设施：减少对外部服务(Bors)的依赖，降低维护成本
2. 更好的同步兼容性：避免了Bors特有的合并提交，解决了与上游Rust项目同步时的兼容性问题
3. 官方推荐方案：符合Rust基础设施团队对中小型项目的技术推荐
4. 更直观的工作流：开发者可以直接在GitHub界面查看和管理合并队列状态

潜在挑战与解决方案

迁移过程中，团队也考虑到了可能面临的挑战：

延迟增加是最主要的顾虑。与Bors不同，GitHub合并队列需要等待PR的初步CI通过后才能进入队列，这意味着从提交到最终合并需要经历两轮CI时间。对于Miri项目而言，CI时间通常在30分钟以内，因此总延迟控制在1小时左右，这在大多数情况下是可以接受的。

团队还探讨了通过调整CI配置来优化工作流的可能性，比如将PR阶段的CI标记为非阻塞状态。但考虑到这可能造成UI显示上的混淆，最终决定保持标准配置，接受这一合理的延迟增加。

实施与效果

迁移工作通过两个主要PR完成：一个更新了Miri项目的配置，另一个修改了团队仓库的相关设置。整个过程平稳顺利，没有出现重大技术障碍。

从实际使用体验来看，新的合并队列系统运行稳定，开发者反馈积极。虽然工作流略有变化，但整体上简化了代码合并过程，减少了对外部工具的依赖。

结论

Miri项目从Bors迁移到GitHub合并队列的决策，体现了团队对开发效率与基础设施稳定性的平衡考量。这一变更不仅解决了长期存在的技术痛点，也顺应了GitHub平台功能发展的趋势。对于类似规模的开源项目，这一经验值得参考，特别是在评估代码合并系统的选择时，需要综合考虑项目特点、团队规模和维护成本等多方面因素。