背景

作为一款开源的分布式图数据库产品，Nebula 所有的研发流程都在 GitHub 上运作。基于 GitHub 生态 Nebula 技术团队有一套 pr 的自动化流程：每次 pr 提上来的时候， pull request bot 跑一遍测试，看看这个 pr merge 到主分支以后是否可以保证当前的一些功能还可以继续正常运行。

这时候，问题出现了：每个 pr 上来一次都要跑一遍测试，这样的操作既费时又对测试机造成不必要的消耗。于是，Nebula 研发团队打算演变现有的 pr 合并机器人。

本文主要讲述如何在原先的设定下，优化设计，从而节省测试资源。

设计思路

基于现有 bot 的实现思路，来开发一款新的 bot 优化 pr 合并。新的 bot 主要特点是，利用 github action 提供的 on schedule 功能，在每隔一段时间后可以自动执行所有 pull request 合并后的测试，这样一来就不需要每个 pull request 都跑一次 CI，节省了时间和性能消耗。若测试失败，则用随机剔除的方案剔除其中某个 pull request 然后继续执行测试，直到测试通过或者没用可用的 pull request 为止。随后将此次测试通过中的包含的 pull request merge 到主分支中，并且提供发送此次 merge 信息到钉钉群里的功能。

假设用户有一个新的 pull request 提上来，它的一生需要经历：

1. pull request 被 reviewers approve
2. Repository maintainer 评论/merge，表明同意 merge
3. 完成 1，2 后， pull request 就会被 bot 识别为可 merge 的 pull request
4. bot 将所有标为可 merge 的 pull request 预加载到 runner 的本地基于 master 的分支中进行 ci 测试
5. 测试通过，pull request 被 merge 到主分支；测试失败，bot 会随机剔除现有包含的 pull request，再进行测试，直到测试通过或者没有可用的分支为止。
6. （可选）bot 将本次 merge 的结果发送到钉钉群中

需要注意：

• 使用 auto-merge-bot 时，repository 需要在 GitHub orgnization 中配置一个 team，这个 team 里的部分 member 的 role 需被标识为 maintainer，对应上述步骤2。

• maintainer 可以通过评论 / merge 表示同意 merge 该 pull request，也可以通过评论 / wait a minute 或者删除评论取消 merge，但是目前如果 bot 已经在运行中，只能通过手动停止此次 bot 的 workflow 来取消 merge，在未来版本中会加入该功能。
• 关于钉钉群发送功能，需在钉钉群中配置机器人，详见 https://developers.dingtalk.com/document/robots/custom-robot-access 和 https://developers.dingtalk.com/document/robots/customize-robot-security-settings，目前仅支持加签的安全设置方式。
• ci 测试的代码需要用户在入参中传入。
• Github Action 的 schedule 有延迟，并不会按照指定的时间如期运行，通常延迟 15 - 30 分钟。

测试用例

 ...

 on:
  schedule:
    - cron: '* */1 * * *'  --- 每小时跑一次
  workflow_dispatch:

 ...

    - name: Run merge script
      uses: klay-ke/auto-merge-pr@master  --- 该地址以后可能会改
      id: merge-pr
      with:
        send-to-dingtalk-group: true
        dingtalk-access-token: ${{ secrets.DINGTALK_ACCESS_TOKEN }}
        dingtalk-secret: ${{ secrets.DINGTALK_SECRET }}
        maintainer-team-name: ${{ secrets.MAINTAINER_TEAM_NAME }}
        gh-token: ${{ secrets.GH_TOKEN }}
        ci-command: 'bash ./build.sh'

输入

输出

可通过 ${{ steps.{action设置的id - 对应用例中的merge-pr}.outputs.{参数名} }} 在后续 step 中读取输出；

以上。