我用 GitHub Action 搭建了一套 CI/CD 系統(tǒng)
本文是 Nebula Graph 工程師利用 GitHub Action 搭建 CI/CD 系統(tǒng)的實(shí)踐，希望能夠?qū)ψx者有所幫助，同時(shí)也歡迎讀者留言與作者進(jìn)行交流。
1. 緣起
Nebula Graph 最早的自動(dòng)化測試是使用搭建在 Azure 上的 Jenkins，配合著 GitHub 的 Webhook 實(shí)現(xiàn)的，在用戶提交 Pull Request 時(shí)，加個(gè) ready-for-testing 的 label 再評論一句 Jenkins go 就可以自動(dòng)的運(yùn)行相應(yīng)的 UT 測試，效果如下：
因?yàn)槭亲庥玫?Azure 的云主機(jī)，加上 nebula 的編譯要求的機(jī)器配置較高，而且任務(wù)的觸發(fā)主要集中在白天。所以上述的方案性價(jià)比較低，從去年團(tuán)隊(duì)就在考慮尋找替代的方案，準(zhǔn)備下線 Azure 上的測試機(jī)，并且還要能提供多環(huán)境的測試方案。
調(diào)研了一圈現(xiàn)有的產(chǎn)品主要有：
- TravisCI
- CircleCI
- Azure Pipeline
- Jenkins on k8s（自建）
雖然上面的產(chǎn)品對開源項(xiàng)目有些限制，但整體都還算比較友好。
鑒于之前 GitLab CI 的使用經(jīng)驗(yàn)，體會到如果能跟 GitHub 深度集成那當(dāng)然是首選。所謂“深度”表示可以共享 GitHub 的整個(gè)開源的生態(tài)以及完美的 API 調(diào)用（后話）。恰巧 2019，GitHub Action 2.0 橫空出世，Nebula Graph 便勇敢的入了坑。
這里簡單概述一下我們在使用 GitHub Action 時(shí)體會到的優(yōu)點(diǎn)：
- 免費(fèi)。開源項(xiàng)目可以免費(fèi)使用 Action 的所有功能，而且機(jī)器配置較高。
- 開源生態(tài)好。在整個(gè) CI 的流程里，可以直接使用 GitHub 上的所有開源的 Action，哪怕就是沒有滿足需求的 Action，自己上手寫也不是很麻煩，而且還支持 docker 定制，用 bash 就可以完成一個(gè)專屬的 Action。
- 支持多種系統(tǒng)。Windows、macOS 和 Linux 都可以一鍵使用，跨平臺簡單方便。
- 可跟 GitHub 的 API 互動(dòng)。通過 GITHUB_TOKEN 可以直接訪問 GitHub API V3，想上傳文件，檢查 PR 狀態(tài)，使用 curl 命令即可完成。
- 自托管。只要提供 workflow 的描述文件，將其放置到 .github/workflows/ 目錄下，每次提交便會自動(dòng)觸發(fā)執(zhí)行新的 action run。
- Workflow 描述文件改為 YAML 格式。目前的描述方式要比 Action 1.0 中的 workflow 文件更加簡潔易讀。
下面在講實(shí)踐之前還是要先講講 Nebula Graph 的需求：首要目標(biāo)比較明確就是自動(dòng)化測試。
作為數(shù)據(jù)庫產(chǎn)品，測試怎么強(qiáng)調(diào)也不為過。Nebula Graph 的測試主要分單元測試和集成測試。用 GitHub Action 其實(shí)主要瞄準(zhǔn)的是單元測試，然后再給集成測試做些準(zhǔn)備，比如 docker 鏡像構(gòu)建和安裝程序打包。順帶再解決一下 PM 小姐姐的發(fā)布需求，就整個(gè)構(gòu)建起來了第一版的 CI/CD 流程。
2. PR 測試
Nebula Graph 作為托管在 GitHub 上的開源項(xiàng)目，首先要解決的測試問題就是當(dāng)貢獻(xiàn)者提交了 PR 請求后，如何才能快速地進(jìn)行變更驗(yàn)證？主要有以下幾個(gè)方面。
- 符不符合編碼規(guī)范；
- 能不能在不同系統(tǒng)上都編譯通過；
- 單測有沒有失??；
- 代碼覆蓋率有沒有下降等。
只有上述的要求全部滿足并且有至少兩位 reviewer 的同意，變更才能進(jìn)入主干分支。
借助于 cpplint 或者 clang-format 等開源工具可以比較簡單地實(shí)現(xiàn)要求 1，如果此要求未通過驗(yàn)證，后面的步驟就自動(dòng)跳過，不再繼續(xù)執(zhí)行。
對于要求 2，我們希望能同時(shí)在目前支持的幾個(gè)系統(tǒng)上運(yùn)行 Nebula 源碼的編譯驗(yàn)證。那么像之前在物理機(jī)上直接構(gòu)建的方式就不再可取，畢竟一臺物理機(jī)的價(jià)格已經(jīng)高昂，何況一臺還不足夠。為了保證編譯環(huán)境的一致性，還要盡可能的減少機(jī)器的性能損失，最終采用了 docker 的容器化構(gòu)建方式。再借助 Action 的 matrix 運(yùn)行策略 和對 docker 的支持，還算順利地將整個(gè)流程走通。
運(yùn)行的大概流程如上圖所示，在 vesoft-inc/nebula-dev-docker 項(xiàng)目中維護(hù) nebula 編譯環(huán)境的 docker 鏡像，當(dāng)編譯器或者 thirdparty 依賴升級變更時(shí)，自動(dòng)觸發(fā) docker hub 的 Build 任務(wù)（見下圖）。當(dāng)新的 Pull Request 提交以后，Action 便會被觸發(fā)開始拉取最新的編譯環(huán)境鏡像，執(zhí)行編譯。
針對 PR 的 workflow 完整描述見文件 pull_request.yaml。同時(shí)，考慮到并不是每個(gè)人提交的 PR 都需要立即運(yùn)行 CI 測試，且自建的機(jī)器資源有限，對 CI 的觸發(fā)做了如下限制：
- 只有 lint 校驗(yàn)通過的 PR 才會將后續(xù)的 job 下發(fā)到自建的 runner，lint 的任務(wù)比較輕量，可以使用 GitHub Action 托管的機(jī)器來執(zhí)行，無需占用線下的資源。
- 只有添加了 ready-for-testing label 的 PR 才會觸發(fā) action 的執(zhí)行，而 label 的添加有權(quán)限的控制。進(jìn)一步優(yōu)化 runner 被隨意觸發(fā)的情況。對 label 的限制如下所示：
- jobs:
- lint:
- name: cpplint
- if: contains(join(toJson(github.event.pull_request.labels.*.name)), 'ready-for-testing')
在 PR 中執(zhí)行完成后的效果如下所示：
Code Coverage 的說明見博文：圖數(shù)據(jù)庫 Nebula Graph 的代碼變更測試覆蓋率實(shí)踐。
https://nebula-graph.io/cn/posts/integrate-codecov-test-coverage-with-nebula-graph/
3. Nightly 構(gòu)建
在 Nebula Graph 的集成測試框架中，希望能夠在每天晚上對 codebase 中的代碼全量跑一遍所有的測試用例。同時(shí)有些新的特性，有時(shí)也希望能快速地打包交給用戶體驗(yàn)使用。這就需要 CI 系統(tǒng)能在每天給出當(dāng)日代碼的 docker 鏡像和 rpm/deb 安裝包。
GitHub Action 被觸發(fā)的事件類型除了 pull_request，還可以執(zhí)行 schedule 類型。schedule 類型的事件可以像 crontab 一樣，讓用戶指定任何重復(fù)任務(wù)的觸發(fā)時(shí)間，比如每天凌晨兩點(diǎn)執(zhí)行任務(wù)如下所示：
- on:
- schedule:
- - cron: '0 18 * * *'
因?yàn)?GitHub 采用的是 UTC 時(shí)間，所以東八區(qū)的凌晨 2 點(diǎn)，就對應(yīng)到 UTC 的前日 18 時(shí)。
docker
每日構(gòu)建的 docker 鏡像需要 push 到 docker hub 上，并打上 nightly 的標(biāo)簽，集成測試的 k8s 集群，將 image 的拉取策略設(shè)置為 Always，每日觸發(fā)便能滾動(dòng)升級到當(dāng)日最新進(jìn)行測試。因?yàn)楫?dāng)日的問題目前都會盡量當(dāng)日解決，便沒有再給 nightly 的鏡像再額外打一個(gè)日期的 tag。對應(yīng)的 action 部分如下所示：
- - name: Build image
- env:
- IMAGE_NAME: ${{ secrets.DOCKER_USERNAME }}/nebula-${{ matrix.service }}:nightly
- run: |
- docker build -t ${IMAGE_NAME} -f docker/Dockerfile.${{ matrix.service }} .
- docker push ${IMAGE_NAME}
- shell: bash
package
GitHub Action 提供了 artifacts 的功能，可以讓用戶持久化 workflow 運(yùn)行過程中的數(shù)據(jù)，這些數(shù)據(jù)可以保留 90 天。對于 nightly 版本安裝包的存儲而言，已經(jīng)綽綽有余。利用官方提供的 actions/upload-artifact@v1 action，可以方便的將指定目錄下的文件上傳到 artifacts。最后 nightly 版本的 nebula 的安裝包如下圖所示。
上述完整的 workflow 文件見 package.yaml
https://github.com/vesoft-inc/nebula/blob/master/.github/workflows/package.yaml
4. 分支發(fā)布
為了更好地維護(hù)每個(gè)發(fā)布的版本和進(jìn)行 bugfix，Nebula Graph 采用分支發(fā)布的方式。即每次發(fā)布之前進(jìn)行 code freeze，并創(chuàng)建新的 release 分支，在 release 分支上只接受 bugfix，而不進(jìn)行 feature 的開發(fā)。bugfix 還是會在開發(fā)分支上提交，最后 cherrypick 到 release 分支。
在每次 release 時(shí)，除了 source 外，我們希望能把安裝包也追加到 assets 中方便用戶直接下載。如果每次都手工上傳，既容易出錯(cuò)，也非常耗時(shí)。這就比較適合 Action 來自動(dòng)化這塊的工作，而且，打包和上傳都走 GitHub 內(nèi)部網(wǎng)絡(luò)，速度更快。
在安裝包編譯好后，通過 curl 命令直接調(diào)用 GitHub 的 API，就能上傳到 assets 中，具體腳本 內(nèi)容如下所示：
- curl --silent \
- --request POST \
- --url "$upload_url?name=$filename" \
- --header "authorization: Bearer $github_token" \
- --header "content-type: $content_type" \
- --data-binary @"$filepath"
同時(shí)，為了安全起見，在每次的安裝包發(fā)布時(shí)，希望可以計(jì)算安裝包的 checksum 值，并將其一同上傳到 assets 中，以便用戶下載后進(jìn)行完整性校驗(yàn)。具體步驟如下所示：
- jobs:
- package:
- name: package and upload release assets
- runs-on: ubuntu-latest
- strategy:
- matrix:
- os:
- - ubuntu1604
- - ubuntu1804
- - centos6
- - centos7
- container:
- image: vesoft/nebula-dev:${{ matrix.os }}
- steps:
- - uses: actions/checkout@v1
- - name: package
- run: ./package/package.sh
- - name: vars
- id: vars
- env:
- CPACK_OUTPUT_DIR: build/cpack_output
- SHA_EXT: sha256sum.txt
- run: |
- tag=$(echo ${{ github.ref }} | rev | cut -d/ -f1 | rev)
- cd $CPACK_OUTPUT_DIR
- filename=$(find . -type f \( -iname \*.deb -o -iname \*.rpm \) -exec basename {} \;)
- sha256sum $filename > $filename.$SHA_EXT
- echo "::set-output name=tag::$tag"
- echo "::set-output name=filepath::$CPACK_OUTPUT_DIR/$filename"
- echo "::set-output name=shafilepath::$CPACK_OUTPUT_DIR/$filename.$SHA_EXT"
- shell: bash
- - name: upload release asset
- run: |
- ./ci/scripts/upload-github-release-asset.sh github_token=${{ secrets.GITHUB_TOKEN }} repo=${{ github.repository }} tag=${{ steps.vars.outputs.tag }} filepath=${{ steps.vars.outputs.filepath }}
- ./ci/scripts/upload-github-release-asset.sh github_token=${{ secrets.GITHUB_TOKEN }} repo=${{ github.repository }} tag=${{ steps.vars.outputs.tag }} filepath=${{ steps.vars.outputs.shafilepath }}
上述完整的 workflow 文件見 release.yaml。
https://github.com/vesoft-inc/nebula/blob/master/.github/workflows/release.yaml
5. 命令
GitHub Action 為 workflow 提供了一些 命令 方便在 shell 中進(jìn)行調(diào)用，來更精細(xì)地控制和調(diào)試每個(gè)步驟的執(zhí)行。常用的命令如下：
set-output
有時(shí)在 job 的 steps 之間需要傳遞一些結(jié)果，這時(shí)就可以通過 echo "::set-output name=output_name::output_value" 的命令形式將想要輸出的 output_value 值設(shè)置到 output_name 變量中。
在接下來的 step 中，可以通過 $ {{steps.step_id.outputs.output_name}} 的方式引用上述的輸出值。
上節(jié)中上傳 asset 的 job 中就使用了上述的方式來傳遞文件名稱。一個(gè)步驟可以通過多次執(zhí)行上述命令來設(shè)置多個(gè)輸出。
set-env
同 set-output 一樣，可以為后續(xù)的步驟設(shè)置環(huán)境變量。語法：echo "::set-env name={name}::{value}" 。
add-path
將某路徑加入到 PATH 變量中，為后續(xù)步驟使用。語法：echo "::add-path::{path}" 。
6. Self-Hosted Runner
除了 GitHub 官方托管的 runner 之外，Action 還允許使用線下自己的機(jī)器作為 Runner 來跑 Action 的 job。在機(jī)器上安裝好 Action Runner 之后，按照 教程，將其注冊到項(xiàng)目后，在 workflow 文件中通過配置 runs-on: self-hosted 即可使用。
self-hosted 的機(jī)器可以打上不同的 label，這樣便可以通過 不同的標(biāo)簽 來將任務(wù)分發(fā)到特定的機(jī)器上。比如線下的機(jī)器安裝有不同的操作系統(tǒng)，那么 job 就可以根據(jù) runs-on 的 label 在特定的機(jī)器 上運(yùn)行。self-hosted 也是一個(gè)特定的標(biāo)簽。
安全
GitHub 官方是不推薦開源項(xiàng)目使用 Self-Hosted 的 runner 的，原因是任何人都可以通過提交 PR 的方式，讓 runner 的機(jī)器運(yùn)行危險(xiǎn)的代碼對其所在的環(huán)境進(jìn)行攻擊。
但是 Nebula Graph 的編譯需要的存儲空間較大，且 GitHub 只能提供 2 核的環(huán)境來編譯，不得已還是選擇了自建 Runner?？紤]到安全的因素，進(jìn)行了如下方面的安全加固：
虛擬機(jī)部署
所有注冊到 GitHub Action 的 runner 都是采用虛擬機(jī)部署，跟宿主機(jī)做好第一層的隔離，也更方便對每個(gè)虛擬機(jī)做資源分配。一臺高配置的宿主機(jī)可以分配多個(gè)虛擬機(jī)讓 runner 來并行地跑所有收到的任務(wù)。
如果虛擬機(jī)出了問題，可以方便地進(jìn)行環(huán)境復(fù)原的操作。
網(wǎng)絡(luò)隔離
將所有 runner 所在的虛擬機(jī)隔離在辦公網(wǎng)絡(luò)之外，使其無法直接訪問公司內(nèi)部資源。即便有人通過 PR 提交了惡意代碼，也讓其無法訪問公司內(nèi)部網(wǎng)絡(luò)，造成進(jìn)一步的攻擊。
Action 選擇
盡量選擇大廠和官方發(fā)布的 action，如果是使用個(gè)人開發(fā)者的作品，最好能檢視一下其具體實(shí)現(xiàn)代碼，免得出現(xiàn)網(wǎng)上爆出來的 泄漏隱私密鑰 等事情發(fā)生。
比如 GitHub 官方維護(hù)的 action 列表：
https://github.com/actions
私鑰校驗(yàn)
GitHub Action 會自動(dòng)校驗(yàn) PR 中是否使用了一些私鑰，除卻 GITHUB_TOKEN 之外的其他私鑰（通過 $ {{secrets.MY_TOKENS}} 形式引用）均是不可以在 PR 事件觸發(fā)的相關(guān)任務(wù)中使用，以防用戶通過 PR 的方式私自打印輸出竊取密鑰。
環(huán)境搭建與清理
對于自建的 runner，在不同任務(wù)（job）之間做文件共享是方便的，但是最后不要忘記每次在整個(gè) action 執(zhí)行結(jié)束后，清理產(chǎn)生的中間文件，不然這些文件有可能會影響接下來的任務(wù)執(zhí)行和不斷地占用磁盤空間。
- - name: Cleanup
- if: always()
- run: rm -rf build
將 step 的運(yùn)行條件設(shè)置為 always() 確保每次任務(wù)都要執(zhí)行該步驟，即便中途出錯(cuò)。
基于 Docker 的 Matrix 并行構(gòu)建
因?yàn)?Nebula Graph 需要在不同的系統(tǒng)上做編譯驗(yàn)證，在構(gòu)建方式上采用了容器的方案，原因是構(gòu)建時(shí)不同環(huán)境的隔離簡單方便，GitHub Action 可以原生支持基于 docker 的任務(wù)。
Action 支持 matrix 策略運(yùn)行任務(wù)的方式，類似于 TravisCI 的 build matrix。通過配置不同系統(tǒng)和編譯器的組合，我們可以方便地設(shè)置在每個(gè)系統(tǒng)下使用 gcc 和 clang 來同時(shí)編譯 nebula 的源碼，如下所示：
- jobs:
- build:
- name: build
- runs-on: ubuntu-latest
- strategy:
- fail-fast: false
- matrix:
- os:
- - centos6
- - centos7
- - ubuntu1604
- - ubuntu1804
- compiler:
- - gcc-9.2
- - clang-9
- exclude:
- - os: centos7
- compiler: clang-9
上述的 strategy 會生成 8 個(gè)并行的任務(wù)（4 os x 2 compiler），每個(gè)任務(wù)都是（os, compiler）的一個(gè)組合。這種類似矩陣的表達(dá)方式，可以極大的減少不同緯度上的任務(wù)組合的定義。
如果想排除 matrix 中的某個(gè)組合，只要將組合的值配置到 exclude 選項(xiàng)下面即可。如果想在任務(wù)中訪問 matrix 中的值，也只要通過類似 $ {{matrix.os}} 獲取上下文變量值的方式拿到。這些方式讓你定制自己的任務(wù)時(shí)都變得十分方便。
運(yùn)行時(shí)容器
我們可以為每個(gè)任務(wù)指定運(yùn)行時(shí)的一個(gè)容器環(huán)境，這樣該任務(wù)下的所有步驟（steps）都會在容器的內(nèi)部環(huán)境中執(zhí)行。相較于在每個(gè)步驟中都套用 docker 命令要簡潔明了。
- container:
- image: vesoft/nebula-dev:${{ matrix.os }}
- env:
- CCACHE_DIR: /tmp/ccache/${{ matrix.os }}-${{ matrix.compiler }}
對容器的配置，像在 docker compose 中配置 service 一樣，可以指定 image/env/ports/volumes/options 等等 參數(shù)。在 self-hosted 的 runner 中，可以方便地將宿主機(jī)上的目錄掛載到容器中做文件的共享。
正是基于 Action 上面的容器特性，才方便的在 docker 內(nèi)做后續(xù)編譯的緩存加速。
7. 編譯加速
Nebula Graph 的源碼采用 C++ 編寫，整個(gè)構(gòu)建過程時(shí)間較長，如果每次 CI 都完全地重新開始，會浪費(fèi)許多計(jì)算資源。因?yàn)槊颗_ runner 跑的（容器）任務(wù)不定，需要對每個(gè)源文件及對應(yīng)的編譯過程進(jìn)行精準(zhǔn)判別才能確認(rèn)該源文件是否真的被修改。目前使用最新版本的 ccache 來完成緩存的任務(wù)。
雖然 GitHub Action 本身提供 cache 的功能，由于 Nebula Graph 目前單元測試的用例采用靜態(tài)鏈接，編譯后體積較大，超出其可用的配額，遂使用本地緩存的策略。
ccache
ccache 是個(gè)編譯器的緩存工具，可以有效地加速編譯的過程，同時(shí)支持 gcc/clang 等編譯器。Nebula Graph 使用 C++ 14 標(biāo)準(zhǔn)，低版本的 ccache 在兼容性上有問題，所以在所有的 vesoft/nebula-dev 鏡像 中都采用手動(dòng)編譯的方式安裝。
Nebula Graph 在 cmake 的配置中自動(dòng)識別是否安裝了 ccache，并決定是否對其打開啟用。所以只要在容器環(huán)境中對 ccache 做些配置即可，比如在 ccache.conf 中配置其最大緩存容量為 1 G，超出后自動(dòng)替換較舊緩存。
- max_size = 1.0G
ccache.conf 配置文件最好放置在緩存目錄下，這樣 ccache 可方便讀取其中內(nèi)容。
tmpfs
tmpfs 是位于內(nèi)存或者 swap 分區(qū)的臨時(shí)文件系統(tǒng)，可以有效地緩解磁盤 IO 帶來的延遲，因?yàn)?self-hosted 的主機(jī)內(nèi)存足夠，所以將 ccache 的目錄掛載類型改為 tmpfs，來減少 ccache 讀寫時(shí)間。在 docker 中使用 tmpfs 的掛載類型可以參考 相應(yīng)文檔。相應(yīng)的配置參數(shù)如下：
- env:
- CCACHE_DIR: /tmp/ccache/${{ matrix.os }}-${{ matrix.compiler }}
- options: --mount type=tmpfs,destination=/tmp/ccache,tmpfs-size=1073741824 -v /tmp/ccache/${{ matrix.os }}-${{ matrix.compiler }}:/tmp/ccache/${{ matrix.os }}-${{ matrix.compiler }}
將所有 ccache 產(chǎn)生的緩存文件，放置到掛載為 tmpfs 類型的目錄下。
并行編譯
make 本身即支持多個(gè)源文件的并行編譯，在編譯時(shí)配置 -j $(nproc) 便可同時(shí)啟動(dòng)與核數(shù)相同的任務(wù)數(shù)。在 action 的 steps 中配置如下：
- - name: Make
- run: cmake --build build/ -j $(nproc)
8. 坑
說了那么多的優(yōu)點(diǎn)，那有沒有不足呢？使用下來主要體會到如下幾點(diǎn)：
只支持較新版本的系統(tǒng)。很多 Action 是基于較新的 Nodejs 版本開發(fā)，沒法方便地在類似 CentOS 6 等老版本 docker 容器中直接使用。否則會報(bào) Nodejs 依賴的庫文件找不到，從而無法正常啟動(dòng) action 的執(zhí)行。因?yàn)?Nebula Graph 希望可以支持 CentOS 6，所以在該系統(tǒng)下的任務(wù)不得不需要特殊處理。
不能方便地進(jìn)行本地驗(yàn)證。雖然社區(qū)有個(gè)開源項(xiàng)目 act，但使用下來還是有諸多限制，有時(shí)不得不通過在自己倉庫中反復(fù)提交驗(yàn)證才能確保 action 的修改正確。
目前還缺少比較好的指導(dǎo)規(guī)范，當(dāng)定制的任務(wù)較多時(shí)，總有種在 YAML 配置中寫程序的感受。目前的做法主要有以下三種：
- 根據(jù)任務(wù)拆分配置文件。
- 定制專屬 action，通過 GitHub 的 SDK 來實(shí)現(xiàn)想要的功能。
- 編寫大的 shell 腳本來完成任務(wù)內(nèi)容，在任務(wù)中調(diào)用該腳本。
目前針對盡量多使用小任務(wù)的組合還是使用大任務(wù)的方式，社區(qū)也沒有定論。不過小任務(wù)組合的方式可以方便地定位任務(wù)失敗位置以及確定每步的執(zhí)行時(shí)間。
Action 的一些歷史記錄目前無法清理，如果中途更改了 workflows 的名字，那么老的 check runs 記錄還是會一直保留在 Action 頁面，影響使用體驗(yàn)。
目前還缺少像 GitLab CI 中手動(dòng)觸發(fā) job/task 運(yùn)行的功能。無法運(yùn)行中間進(jìn)行人工干預(yù)。
action 的開發(fā)也在不停的迭代中，有時(shí)需要維護(hù)一下新版的升級，比如：checkout@v2
不過總體來說，GitHub Action 是一個(gè)相對優(yōu)秀的 CI/CD 系統(tǒng)，畢竟站在 GitLab CI/Travis CI 等前人肩膀上的產(chǎn)品，還是有很多經(jīng)驗(yàn)可以借鑒使用。
9. 后續(xù)
定制 Action
前段時(shí)間 docker 發(fā)布了自己的第一款 Action，簡化用戶與 docker 相關(guān)的任務(wù)。后續(xù)，針對 Nebula Graph 的一些 CI/CD 的復(fù)雜需求，我們亦會定制一些專屬的 action 來給 nebula 的所有 repo 使用。通用的就會創(chuàng)建獨(dú)立的 repo，發(fā)布到 action 市場里，比如追加 assets 到 release 功能。專屬的就可以放置 repo 的 .github/actions 目錄下。
這樣就可以簡化 workflows 中的 YAML 配置，只要 use 某個(gè)定制 action 即可。靈活性和拓展性都更優(yōu)。
跟釘釘 /slack 等 IM 集成
通過 GitHub 的 SDK 可以開發(fā)復(fù)雜的 action 應(yīng)用，再結(jié)合 釘釘/slack 等 bot 的定制，可以實(shí)現(xiàn)許多自動(dòng)化的有意思的小應(yīng)用。比如，當(dāng)一個(gè) PR 被 2 個(gè)以上的 reviewer approve 并且所有的 check runs 都通過，那么就可以向釘釘群里發(fā)消息并 @ 一些人讓其去 merge 該 PR。免去了每次都去 PR list 里面 check 每個(gè) PR 狀態(tài)的辛苦。
當(dāng)然圍繞 GitHub 的周邊通過一些 bot 還可以迸發(fā)許多有意思的玩法。
