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。

項目介紹

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 配置文件如圖

整體能夠分爲三塊：

1. 命令區：說明了安裝階段和執行階段的操做有哪些
2. 條件區：指定了這個配置文件在哪些條件下會生效
3. 部署區：寫明瞭構建產物如何進行部署

在命令區中，有預置的安裝過程和後續的執行過程。在安裝過程當中，安裝了一些依賴，並將當前的 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 流程拆分紅三個部分：

1. 生成 badge 文件，應當跟隨每一次提交進行
2. 生成 status 文件，執行時間較長，能夠按期執行
3. 根據拉取請求內容進行整理，作覈驗

則將咱們的配置文件拆分紅三個不一樣的文件：

也得益於拆分開，則在 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 行，變得更加的精簡、易懂。

8. 修改 GitHub 的分支保護條件

爲了確保修改符合標準，咱們限制了新的拉取請求必須經過 CI 檢查，才能合併進入 master 分支，所以，也須要修改相應的分支保護規則，確保設定相應的保護。

一些注意事項

1. 環境變量不一樣

若是你依賴了環境變量，則須要進行相應的修改。或者能夠像我同樣，先經過 set-env 來讓本地擁有臨時的環境變量，後續再逐步進行遷移。

2. Action 運行依賴要注意安全

Action 執行過程當中會有兩個部分。Action 自己流程依賴於 master 分支，但執行過程當中調用的腳本是根據源決定的，所以，從安全角度來看，你應當儘量將全部的流程放在 Action 中，而不是放在你的源碼目錄中。

3. 如何觸發 CI 的 Pull Request 檢查？

在進行 Pull Request 測試的時候，須要不斷觸發不一樣的 Commit ，你能夠經過執行 git commit --allow-empty -m "Trigger notification" && git push 來觸發一個空白的 commit， 推送到 Github 後，就能夠再次觸發 pull request 的構建，提高構建的效率。

總結

經過對 TravisCI 的流程整理、代碼修改等流程，咱們將以前的 Travis-CI 遷移至速度更快、性能更好的 GitHub Action ，一方面能夠優化咱們的工做流，另外一方面，也讓咱們的代碼更加簡潔明瞭。

對於還在使用 Travis CI 的項目來講，也能夠考慮遷移到 GitHub Action 中，來優化本身的工做流。

參考閱讀

• https://mauricius.dev/run-and...
• https://jeffrafter.com/workin...
• https://developer.okta.com/bl...