GitHub 自動合併 pr 的機器人——auto-merge-bot

語言: CN / TW / HK

本文首發於 Nebula Graph Community 公眾號

背景

作為一款開源的分散式圖資料庫產品,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。

測試用例

...

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

 ...

    - name: Run merge script
      uses: klay-ke/[email protected]  --- 該地址以後可能會改
      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 中讀取輸出;

以上。

Nebula 社群首屆徵文活動正式開啟啦 獎品豐厚,全場景覆蓋:擼碼機械鍵盤、手機無線充、健康小助手智慧手環,更有資料庫設計、知識圖譜實踐書籍等你來領,還有 Nebula 精緻周邊送不停

歡迎對 Nebula 有興趣、喜鑽研的小夥伴來書寫自己和 Nebula 有趣的故事呀~

交流圖資料庫技術?加入 Nebula 交流群請先 填寫下你的 Nebula 名片 ,Nebula 小助手會拉你進群~~