GitLab 優勢
- 可以使用有限制的 private repository
- 自帶 CI / CD
- 內建 README 文件 pipeline status / test coverage 標籤
- 公司有需要可以自架(host) GitLab
- 自帶 wiki 頁面
今天這篇文章我們會專注在 CI 的部分
要使用 GitLab CI 有幾個重點
gitlab-ci.yml設定檔- GitLab CI Runner 設定
- 確認 pipeline 執行成功
- 讓 GitLab CI 可以自動抓取 coverage 資訊
- 在 README 文件加上 pipeline status 與 test coverage 標籤
gitlab-ci.yml 設定檔
我們以一個前端專案為範例，我們要利用 GitLab CI 自動跑單元測試 (unit test) 涵蓋率 (coverage) 為目標
我們在 project 根目錄中新增 gitlab-ci.yml 檔案
stages
表示這個 CI 設定檔有兩個 stage 要跑，一個是 install、一個是 test，相對於在 GitLab CI 頁面上，這是同一個 Pipeline，分成兩個 job 來跑。
這個 stage 的名稱只要對應到底下 stage 的名稱即可 (圖片上 stages 中的 install 對應到 stage: install )，自己 stage 區塊的命名 (圖片上的 install_dependency ) 則只會影響到 GitLab 頁面上的 Job 顯示而已。
script
就是這個 stage 要執行的指令，會依序執行。
cache
則是你可以不要讓 GitLab CI 每次都重新拉新的 package，所以在前端專案中我們會把 node_modules 資料夾暫存起來。
這邊甚至可以指定要使用的 docker image file，但需要 GitLab CI Runner 設定與 Server 支援，我們先不討論
GitLab CI Runner
簡單來說，因為 GitLab CI 要執行這些指令，還是要有 Server 去代替 GitLab 執行，這個執行人我們稱為 Runner。
- 共享 Runner (Shared Runners)
- 自架 Runner (Specific Runners)
Shared Runners
共享 Runner 比較簡單，如果你是使用 GitLab 官方，在 repository Settings → CI / CD → Runners
這邊就會有不少官方提供的共享 Runner 可以使用，也不用特別做設定，但有幾個缺點
- 因為是共享，所以 Server 資源也共享，理論上多人使用的情況下速度還是會比較慢。
- 如果是公開的開源專案，完全免費。但如果是私人的專案，則有每個月 2000 分鐘 CI 執行時間的限制。
Specific Runners
由於敝公司使用自架的 GitLab，所以 Shared Runner 資源比較少，我們偏向使用自架 Runner，首先你要找一台電腦或 Server 做為 Runner。
取得註冊需要的 URL 跟 Token
到你們自架的 GitLab repository，在 repository Settings → CI / CD → Runners，在 Specific Runners 的部分已經寫好 URL 跟 Token，請把他記住後面會用到。
這邊我們以 Windows Server 為範例，請以要執行的 account 登入
下載安裝檔
到 GitLab 頁面下載 Windows exe 安裝檔(有分 x86 與 x64)，並改名為 gitlab-runner.exe
到 Server 上註冊 Runner
首先，在 C 槽開一個 gitlab-runner 資料夾，把載回來的 gitlab-runner.exe 放進去，並用管理者權限 (administrator) 在這個資料夾開啟 cmd 視窗。
- 註冊 GitLab 網域 (你們自架 GitLab 的網址)
- 輸入 repository 的 Token
- 給這個 Runner 名稱
- 給這個 Runner 需要的 tag (這邊我們先空白，直接 Enter 下一步)
- 輸入這個 Runner 執行使用的執行軟體 (這邊我們使用最一般的 shell)
這時候我們到自架的 GitLab 上看，應該會看到「剛剛註冊但還沒被連接的 Runner」
這樣我們就完成註冊了，但還沒結束，我們需要把他包成 Windows Service，才能正常執行與自動啟動。
回到 Server 安裝與啟動 Service
一樣回到 cmd，繼續下指令
記住，這邊沒有先 install 是不能 start 的。
這時候你到 Windows Service 看，會看到新的 gitlab-runner 服務並已經啟動。
再回到自架的 GitLab repository，你就會看到 Runner 已經被連接成功。
執行 pipeline 並確認 pipeline 執行成功
到 GitLab repository 的 CI / CD 頁面執行，並等待執行成功
讓 GitLab CI 可以自動抓取 coverage 資訊
其實說穿了他就是用正規表達式去抓取 Runner 出現的所有資訊，取出你需要的部分變成涵蓋率比例，更新到他指定的位置，如果你 repository 的 README 文件有使用這個標籤，自然就會被更新了。
這邊以 React 常用的 Jest 跑 coverage 為例，我們要的其實就是 All files 那一塊，所以我們使用的正規表達式為
/All files[^|]*\|[^|]*\s+([\d\.]+)/
到 repository Settings → CI / CD → General pipelines settings → Test coverage parsing 設定即可。
驗證結果
到 repository 的 CI / CD Job 中，unit-test 的 job 就會有 coverage 的數值
讓 README 文件加上 pipeline status / test coverage 標籤
到 repository Settings → CI / CD → General pipelines settings → Pipeline status 與 Coverage report
把兩段 Markdown 與法複製貼到 README 當中，這樣一進 repository 就可以看到這個 repository 的狀態了，這對於不清楚專案狀態的人，是一個很有幫助的標籤。
結語
由於以前都是使用 Jenkins 作為 CI / CD 服務，這次剛好有機會可以用 GitLab CI 來試試，不愧是 GitLab 最強的功能，yaml 設定檔與支援 docker 真的很強大又方便！
Hi 我是 Ryan，如果這篇文章有幫助到你，請你不吝嗇的給予我鼓掌，那將是我進步的動力！👏
另外，你知道 Medium 一篇文章拍手其實可以拍 50 下嗎？如果你願意，請賜我掌聲，謝謝！
