GitHub合并队列e2e测试重复运行问题及选型咨询

问题1：避免gate.yml重复执行的配置调整 #

核心问题出在合并限制的「最小拉取请求数/等待时间」配置：当前设置的「1个或等待5分钟」远短于e2e测试的10-15分钟耗时。当PR B在PR A启动测试后5分钟内加入队列，合并队列会等待5分钟再尝试合并，但此时PR A已完成合并，基准分支已更新，PR B之前的测试基于旧分支，会被判定为失效，因此触发新的测试。

调整方案：

• 将「等待时间」设为大于等于e2e测试最长耗时（比如15分钟），确保队列等待足够时长，让所有已加入的PR完成测试后再统一合并。这样PR B的测试结果是基于最终合并前的基准分支，无需重复运行。
• 若团队PR合并频率低，可直接关闭等待机制，设置为「有1个PR就立即尝试合并」，但会失去批量合并的效率优化。

另外，当前gate.yml监听merge_group的checks_requested事件，该事件会在合并组更新（如新PR加入、已有PR合并）时重新触发。若需要进一步优化，可在工作流中添加条件判断，仅当合并组首次创建时运行测试，但最可靠的方式还是调整合并队列的等待时间。

问题2：GitHub Merge Queue是否适配你的场景？ #

GitHub Merge Queue完全适配你的需求——它的核心作用就是自动处理基准分支更新，确保PR基于最新代码通过测试后再合并，避免合并冲突和测试失效，正好匹配你「仅在合并前运行e2e测试」的需求。

不建议用自定义工作流替代：自定义工作流需要手动处理基准分支同步、PR合并顺序等复杂逻辑，容易出现遗漏；而Merge Queue已封装好这些机制，仅需调整配置就能适配你的测试耗时。

若坚持自定义工作流，可在PR获得审批后触发e2e测试，但这种方式无法处理「PR获批后基准分支更新」的情况，可能导致合并后代码不符合预期，反而需要更多人工干预。

内容的提问来源于stack exchange，提问作者Ivan Mjartan