大型仓库 PR 高效合并解决方案

[hi-rustin]

大型仓库 PR 高效合并解决方案

Date: 2020-12-09
Authors: Rustin Liu
Status: Draft

背景回顾

在 TiDB 社区中，存在多个大型仓库（tikv/tidb），这些仓库的 CI 每次运行都会消耗大量的资源。为了保证代码的可靠性，我们在 GitHub 上打开了 Require branches to be up to date before merging 分支保护选项，这保证我们每次合并之前都要确保将上游的 Base 合并到 PR 中才能合并。但是也带来浪费 CI 资源测试的问题，例如有 n 个同时可以 merge 的 PR，要跑 O(n^2) 次测试，大大浪费了 CI 资源。

在 cherry-bot 我们采取排队合并的方式来解决资源浪费的问题，但是这样导致的问题是我们的合并变为一次性命令，需要人为不停的去干预，并且因为 CI 不稳定的问题，导致触发大量的 /merge 命令重跑所有测试，浪费 CI 资源。
综上，我们决定在新 bot 中探索新的解决方案。

Goals

• 更高的合并效率

• 更少的人为干预

• 良好的 dashboard

• 高可用性

说明

备选方案1：迁移 CI 至 Prow

简介

Prow 是一个基于 Kubernetes 的 CI/CD 平台。CI 任务可以被各种类型的事件触发并且反馈状态给不同的服务。除了执行任务，Prow 通过 /foo 风格命令以及自动PR合并的策略提供 GitHub 自动化。

在 Prow 中，因为 CI 系统是自己实现的，所以可以获取当前任务是否使用最新的 Base，在合并之前可以重新测试当前 PR 的所有任务。

需要注意的是，Prow 不会每个都单独测试，而是同一仓库的同一分支可以合并的 PR 进行批量重新测试和合并。
所以迁移至 Prow 能解决上述问题。无需人为干预并且具有良好的 dashboard。

成本

• 我们需要将大型仓库的所有 CI 任务从 Jenkins 迁移至 Prow，可能会有上百个 pipeline 的迁移

• 需要 Prow 的学习成本，虽然 Prow 在 k8s 社区和众多云原生社区已投入使用，但是它作为一个开源产品，文档上支持上都不如商业化的 Jenkins

不确定因素

• Prow 是否满足 tidb/tikv 的测试场景

备选方案2：配合 tide 开发一个批量测试机器人

简介

我们可以开发一个批量测试机器人：

1. 为了运行批处理，测试机器人创建一个合并提交，将master与组成该批处理的所有 PR 合并。但是，将其 push 到测试分支（为仓库新建一个用于测试的分支，机器人掌控该分支）。它们看起来像这样：

    Merge #5 #7 #8

    5: Rename `bifurcate()` to `bifurcateCrab()`
    7: Call `bifurcate()` in the `onland` event handler
    8: Fix crash in `drive()`

2. 如果测试通过，则可以合并这些 PR。由于master分支逐点逐个包含了刚刚测试过的确切内容，因此它没有风险。 如果构建失败，测试机器人将遵循称为“二等分”的策略。即，它将批次分为两批，然后将其推入队列。
   在此示例中，第一批将如下所示：
   该批处理仍将失败，因为第二个 PR 会插入对第一个 PR 删除的函数的调用。结果，它将再次被一分为二。

    Merge #5 #7

    5: Rename `bifurcate()` to `bifurcateCrab()`
    7: Call `bifurcate()` in the `onland` event handler

3. 但是，分出的第二个会通过测试：下面的这个 PR 会合并，上面两个 PR 会继续分开尝试。

    Merge #8

    8: Fix crash in `drive()`

4. 再次将剩下两个 PR 一分为二：这个 PR 将测试通过，并且合并进入 master。

    Merge #5

    5: Rename `bifurcate()` to `bifurcateCrab()`

5. 最后只剩下一个 PR：该 PR 会因为上一个 PR 的重命名而失败，因为是最后一个 PR，本次批量合并就会结束。

    Merge #7

    7: Call `bifurcate()` in the `onland` event handler

通过上述方案，我们将 PR 合并的效率提升为 O（E log N），其中 N 是可以合并 PR 的总数，E是失败的PR 的数量。

让该机器人汇报一个测试结果的 status，然后 tide 去检测该 status即可实现完美配合。 并且支持所有 CI，没有 CI 的特殊要求。
需要开发良好的 dashboard 和自动重试机制（因为可能会有 CI 不稳定的因素）。

成本

• 从零开始开发，大约开发周期为 1.5-2 个月（2 人）

不确定因素

• CI 不稳定会导致算法退化，不停重试

备选方案3：配合 tide 开发一个排队测试的机器人

简介

延续备选方案 2 的思路，但是将过程简化，每次将可以合并的 PR 进行排队，并且每次只在测试分支上测试一个 PR。

通过上述方案，我们将 PR 合并的效率提升为 O（N），其中 N 是可以合并 PR 的总数

让该机器人汇报一个测试结果的 status，然后 tide 去检测该 status即可实现完美配合。 并且支持所有 CI，没有 CI 的特殊要求。
需要开发良好的 dashboard 和自动重试机制（因为可能会有 CI 不稳定的因素）。

成本

• 从零开始开发，大约开发周期为 1-1.5 个月（1 人）

不确定因素

• CI 不稳定会导致重试多次之后还无法合并

备选方案4：配合 tide 开发一个重新测试的机器人（使用 tide 的排队并重新测试功能）

在实现备选方案3的过程中发现，我们可以利用 tide 在合并之前重新测试的功能，在 CI 任务中重新测试 PR。在 tide 重新测试时，我们可以将它排队合并的 pr 推送到测试分支，在测试分支中获取测试结果，如果全部通过则该 CI 任务通过成功合并，如果失败则 Tide 不会合并该 PR。

通过上述方案，不仅可以借助 tide 提高合并效率，又可以作为 CI 任务，为每个仓库定制化使用。

该工具将作为 prow 的 CI 任务运行，借助 tide 的 dashboard 并且支持自动重试。

成本

• 从零开始开发，大约开发周期为 1-1.5周（1 人）

不确定因素

• 无

参考实现

• Bors-ng

• Homu

• Tide

[hi-rustin]

@tidb-community-bots/bots-maintainers @tidb-community-bots/bots-reviewers PTAL~

[hi-rustin]

来自 @zhouqiang-cl 的问题：

1. 多个 pr 会产生冲突的可能性比较大
2. 无法控制所有的 pr 都是 bot 合入的，这个时候所有的代码需要再测试一遍
3. 多个 pr 整体测试没问题，不代表每个pr 都没问题

[hi-rustin]

@zhouqiang-cl

1. 冲突在push上去测试之前就会知道，所以没问题
2. 这个问题确实无法抗力，必须用最新的 master，ti-srebot 现在遇到这种情况怎么处理的？
3. 什么情况下会多个 pr 整体测试没问题，单独就不行？

[AndreMouche]

方案三 LGTM

[zhouqiang-cl]

方案三 LGTM

[hi-rustin]

更新解决方案4，PTAL~

[sykp241095]

方案 4 LGTM