CI/CD平臺遷移實踐：從Travis-CI轉移到Github Action
LCTT 的 CI 已經在 Travis CI 上運轉了多年，一致保持著良好的使用體驗。自 2019 年 Github 推出了自家的 CI 工具 Github Action 后，我們就在考慮將 CI 從 Travis-CI 遷移到 Github，以降低維護和溝通的成本，并借助于 GitHub Action Marketplace 實現更強的功能。
項目首頁
最近，因為 TravisCI 屢屢部署出錯，而我們的賬戶因為使用的較多，已經超出了免費使用的限制，以此為契機，將 CI 從 Travis CI 遷移到 GitHub Action。
Travis CI 的提醒
項目介紹
Translate Project 是 LCTT 翻譯組的主要協作項目，幾百位譯者通過 GitHub 進行圍繞開源、Linux、軟件工程等領域的文章翻譯，從 2013 年來，累計了大量的提交，致使項目下有非常多的文件。
Translate Project 借助于 CI 幫助譯者對基本的文章格式和拉取請求進行檢查；并定時執行命令，以進行所有的申請檢查，對于超時未完成翻譯的工作進行回收；對于文章的狀態進行標記，生成相應的徽章。
生成徽章
遷移思路
Travis CI 和 Github Action 在使用方面，其實總體差異不會太大，都是基于 YAML 文件格式來編寫配置文件。不過，和 Travis CI 不同的是，Github Action 支持多個不同的配置文件，因此，你可以根據不同的場景，設定不同的配置文件，降低單個配置的文件的復雜度。
此外，由于我們的腳本中依賴了一些 Travis CI 的環境變量，也需要將其替換為 Github Action 中的相應環境變量，從而確保腳本可以運轉。
改造實踐
1. 分析之前的 CI 流程
我們在 TravisCI 上的 CI 配置文件如圖：
配置文件
總體可以分為三塊：
- 命令區：說明了安裝階段和執行階段的操作有哪些
- 條件區：指定了這個配置文件在哪些條件下會生效
- 部署區：寫明了構建產物如何進行部署
在命令區中，有預置的安裝過程和后續的執行過程。在安裝過程中，安裝了一些依賴，并將當前的 pages 資源克隆到本地，以繼承上一次構建生成的資料。
在條件區則指明了僅作用于 master 分支。
在部署區便是將前面命令區的執行結果進行部署。
基本流程
在實際的執行過程中，還會根據環境變量不同，決定是否要執行特定的命令，這部分在后續的改造過程中，就可以調整部署，拆分到不同的文件中。
構建流程
2. 直接套用配置文件
在完成了基本的分析后，就可以建立新的 Action 配置文件了。由于基本的語法很類似，對于其中的不少內容可以進行直接套用。
比如，我們的配置文件在直接套用后，結果如下
直接套用后的結果
直接套用的文件已經可以直接運行，不過，這里有很多不滿足需要的地方，所以需要做一些修改。
3. 恢復 Travis CI 的環境變量
由于我們使用的 Badge 等生成腳本并非我所編寫，所以在這一次的遷移中，并不打算對齊進行調整，以避免出現故障。而腳本中依賴了一些變量，需要將其重新設置出來。
Github Action 提供了一些方法，可以讓你手動設置環境變量。你可以在你的構建的步驟中，加入如下代碼，從而在構建環境中設定 TRAVIS_BRANCH 和 TRAVIS_EVENT_TYPE 環境變量，確保你可以使用這個環境變量。
- name: Set ENV variables run: | echo "::set-env name=TRAVIS_BRANCH::${TRAVIS_BRANCH:-$(echo $GITHUB_REF | awk 'BEGIN { FS = "/" } ; { print $3 }')}" echo "::set-env name=TRAVIS_EVENT_TYPE::$(if [ "schedule" == "${{ github.event_name }}" ]; then echo "cron"; else echo "${{ github.event_name }}"; fi)"
此外，由于 set-env 這個方法相對比較危險，你還需要在環境變量中，開啟危險函數的執行。
jobs: build: runs-on: ubuntu-latest env: ACTIONS_ALLOW_UNSECURE_COMMANDS: true
4. 拆分配置文件
Github Action 和 TravisCI 不同的一點是你可以將你的 CI 文件拆分成多個文件，從而降低每一個單獨的配置文件的復雜度。
根據前面對于流程的分析，可以將我們的 CI 流程拆分成三個部分：
- 生成
badge文件，應當跟隨每一次提交進行 - 生成
status文件，執行時間較長，可以定期執行 - 根據拉取請求內容進行整理，做核驗
則將我們的配置文件拆分成三個不同的文件：
也得益于拆分開，則在 checker 中就可以免于安裝一些必要的依賴，從而精簡 CI 流程，提升 CI 的執行時間。
5. 測試 CI 的運行情況
在完成了配置文件的編寫和拆分后，就可以進行本地的執行測試。Github Action 寫完了，難免要執行一下，確保整個流程是正常的。
這個時候你可以安裝工具（https://github.com/nektos/act），來在本地執行 Action ，從而確認你的代碼執行是正確的。
如果你是 macOS ，只需要執行 brew install act 就可以安裝 act 工具，來完成 act 的安裝。
安裝完成 act ，就可以通過執行 act 命令來在本地執行 Action ，比如，執行 act pull_request 來觸發 GitHub 的拉取請求事件
通過本地測試后，再將你的配置文件推送到 GitHub 上，進行生產環境的測試即可。
6. 移除 Travis-CI
通過上述的一些步驟，我們完成了從 Travis CI 到 GitHub Action 的遷移，此時，就可以移除項目根目錄中的 .travis.yml 文件，徹底關閉 Travis CI。
7. 替換環境變量
在完成了基本的遷移后，需要對代碼中的一些歷史問題進行修復。在第三步中，我們對于 Travis-CI 的環境變量進行替換，但長期維護的項目應當盡量將這些未標注上下文的信息替換為有文檔標注的，因此，我們需要將其替換。
替換環境變量主要依賴 Github 官方的環境變量說明，你可以參考官方文檔。
簡化后，配置文件從之前的 27 行，減少至 17 行，變得更加的精簡、易懂。
name: LCTT Article Checkeron:pull_request:branches: [master]jobs:build:runs-on: ubuntu-latestenv:PULL_REQUEST_ID: ${{ github.event.number }}steps:- uses: actions/checkout@v2with:fetch-depth: 0- name: "checkout master branch & return to pull request branch"run: CURRENT=$(echo ${{github.ref}} | sed "s|refs/|refs/remotes/|") && git checkout master && git checkout $CURRENT- name: run checkrun: sh ./scripts/check.sh;
8. 修改 GitHub 的分支保護條件
為了確保修改符合標準，我們限制了新的拉取請求必須通過 CI 檢查，才能合并進入 master 分支，因此，也需要修改相應的分支保護規則，確保設定相應的保護。
一些注意事項
1. 環境變量不同
如果你依賴了環境變量，則需要進行相應的修改。或者可以像我一樣，先通過 set-env 來讓本地擁有臨時的環境變量，后續再逐步進行遷移。
2. Action 運行依賴要注意安全
Action 執行過程中會有兩個部分。Action 本身流程依賴于 master 分支，但執行過程中調用的腳本是根據源決定的，因此，從安全角度來看，你應當盡可能將所有的流程放在 Action 中，而不是放在你的源碼目錄中。
3. 如何觸發 CI 的拉取請求檢查？
在進行拉取請求測試的時候，需要不斷觸發不同的提交 ，你可以通過執行 git commit --allow-empty -m "Trigger notification" && git push 來觸發一個空白的提交， 推送到 Github 后，就可以再次觸發拉取請求的構建，提升構建的效率。
總結
通過對 TravisCI 的流程整理、代碼修改等流程，我們將之前的 Travis-CI 遷移至速度更快、性能更好的 GitHub Action ，一方面可以優化我們的工作流，另一方面，也讓我們的代碼更加簡潔明了。
對于還在使用 Travis CI 的項目來說，也可以考慮遷移到 GitHub Action 中，來優化自己的工作流。
