GitLab 簡單的 C++ 專案腳本範例

之前寫過《Gitlab CI/CD 簡單介紹》，大概介紹過 GitLab CI/CD 的架構了，而 Heresy 這邊，其實也針對工作用的 C++ 專案，撰寫了對應的腳本了。

雖然實際上還是有點問題，不過目前看來運作得好像也還算正常，就來稍微分享一下吧～

首先，在系統的配置上，Heresy 這邊是準備了兩台 VM 作為 GitLab Runner，一台是 Windows 10、一台是 Ubuntu，分別處理 Windows 和 Linux 的環境。

而在腳本上，則是分成了分析、建置、測試三個階段：

<!–more–>

其中，三個階段大致上是：

• 分析階段（Analysis）只有跑 cppcheck（官網）來針對原始碼進行靜態分析，這部分是在 Ubuntu 上執行。
• 建置階段（Build）則是在 Windows 與 Linux 上都要進行，分別使用 Build Tools for Visual Studio 和 make + g++ 來針對專案進行建置。
• 最後的測試階段（Test），目前其實沒有真的內容，只是寫好看的。 ^^"

而這邊所撰寫的 .gitlab-ci.yml 內容則如下：

stages:
  - analysis
  - build
  - test # Test do nothing now
cppcheck:
  stage: analysis
  variables:
    GIT_SUBMODULE_STRATEGY: none
  script:
  - cppcheck src/ -j 8 --std=c++14 --output-file=cppcheck.txt
  artifacts:
    paths:
    - cppcheck.txt
  tags:
  - cppcheck
.msvc_template:
  before_script:
  - CHCP 65001 # switch to Unicode for chinese
  - 'call "c:progra~2MICROS~12017BuildToolsVCAuxiliaryBuildvcvars64.bat"' # MSVC env setting
build-windows:
  stage: build
  extends: .msvc_template
  variables:
    GIT_SUBMODULE_STRATEGY: none
  script:
  - git submodule sync --recursive
  - git submodule update --recursive --init --remote external
  - 'msbuild.exe Engine.sln /m /property:Configuration=Release'
  tags:
  - msvc
test-windows:
  stage: test
  variables:
    GIT_STRATEGY: none
    GIT_SUBMODULE_STRATEGY: none
  before_script:
  - CHCP 65001 # switch to Unicode for chinese
  script:
  - echo testing...
  tags:
  - msvc
build-linux:
  stage: build
  variables:
    GIT_SUBMODULE_STRATEGY: none
  script:
  - git submodule sync --recursive
  - git submodule update --recursive --init --remote external_linux
  - make -j
  tags:
  - gcc
test-linux:
  stage: test
  variables:
    GIT_STRATEGY: none
    GIT_SUBMODULE_STRATEGY: none
  script:
  - echo testing...
  tags:
  - gcc

他的格式是採用 YAML（維基百科），基本上又是另一種標記語言了。
針對 GitLab CI/CD 腳本的語法，其實也算滿複雜的、可以寫得很多，這邊就簡單帶過個人有用到的，詳細的語法說明，請參考 GitLab 的官方文件（連結）。

在第一段的「stages」中，定義了 analysis、build、test 三個階段，代表了整個 CI/CD 的 pipeline 流程。

而接下來的 cppcheck、build-windows、test-windows、build-linux、test-linux 這五項，則是分別對應到前面三個 stage 的工作（job）。

另外，比較特別的「.msvc_template」則是一個樣板工作，會被 build-windows 繼承；他定義了一些基本的 Windows 平台的前置設定，對 Heresy 來說主要只是在測試 template job 的功用就是了。

再來，就先就「cppcheck」這個工作（Job）來看比較仔細的內容吧～
這邊可以看到裡面有幾項：

• stage：
  • 對應到前面 stages 裡面定義的階段，同一個階段的多個工作會同時被執行（在有足夠的 Runner 的情況下）。
• variables：
  • 給 GitLab Runner 一些特殊的變數設定。
    這邊是因為在執行 cppcheck 的時候，不需要用到 git submodule 的內容，所以就透過設定 GIT_SUBMODULE_STRATEGY、讓他不要去下載 submodule。
• script：
  • 實際透過 GitLab Runner 來執行的指令。這邊是呼叫 cppcheck、並把結果存到 cppcheck.txt 這個檔案。
• artifacts：
  • 設定這個工作完成後，要留下來的檔案。在這邊就是 cppcheck.txt 了。
    之後這個檔案可以透過 GitLab 網頁介面來取得。
• tags：
  • 透過指定 tag 來指定要使用的 GitLab Runner。
    這邊是寫 cppcheck，代表要有一台 GitLab Runner 的 tag 也要有 cppcheck；而他上面則需要安裝 cppcheck 的程式。

基本上，一個 job 大致上就是這樣了。

而如果要檢視產生的檔案（artifacts、也就是 cppcheck.txt）的內容的話，則是要到 GitLab 的網頁，在專案下的「CI/CD」的「Jobs」裡面，找到對應的工作，打開後就可以在右邊看到「Job artifacts」相關的內容了。

不過也要稍微注意一下，就是 artifact 的檔案實際上是預設有保存期限的，所以比較久以前的檔案，是會自動刪除而看不到的。

再來，則先來看比較簡單的 build-linux 的部分。

這部分大部分的內容都和「cppcheck」這個工作（Job）沒有太大的差異，不過由於編譯完的檔案在這邊並沒有打算留下來，所以沒有去設定 artifact。

而在 script 的部分，這邊基本上就是：

• 關閉了內建的 git submodule 的更新，而是自己更新
• 執行「make -j」來進行平行編譯

之所以要自行處理 submodule 的原因，是因為在 Heresy 這邊的專案裡面，有給 Windows 用的「external」和給 Linux 用的「external_linux」，根據建置的環境，只需要其中一個就好了；而如果是使用預設的方法，就會浪費時間、空間來處理不需要的 submodule。

這邊要注意的是，要先執行「git submodule sync」再執行「git submodule update」，才能正確地追蹤 GitLab 上的 submodule。

至於「build-windows」的部分，大致上和 build-linux 類似。

不過這邊有透過「extends」來繼承「.msvc_template」的內容，不過實際上裡面也只有「before_script」而已；而實際上的內容，是：

• CHCP 65001
  • 將環境的編碼切換成 Unicode，避免中文變成亂碼。
  • 這部分主要是因為使用的環境都是中文的 Windows 的關係，如果是使用英文版的話，應該就不用考慮這個問題了。
• 'call "c:progra~2MICROS~12017BuildToolsVCAuxiliaryBuildvcvars64.bat
  • 再來，則是要呼叫 Visual Studio 的環境設定指令，套用一些給 Visual Studio 建置所需的環境設定。
  • 這邊的「vcvars64.bat」是代表是使用 64 位元原生編譯環境。
  • 路徑的部分，會根據所安裝的 Visual Studio 版本而有所不同。這邊的路徑是 Build Tools for Visual Studio 2017 的。

而實際建置的 script 的部分，除了前面和 build-linux 一樣的 git submodule 處理指令之外，這邊則是透過 msbuild.exe 來建置 Visual C++ 的方案，其指令是：

'msbuild.exe Engine.sln /m /property:Configuration=Release'

至於最後 test-windows、test-linux 的部分呢…恩，老實說，Heresy 這邊的專案並沒有真正的測試程式，所以其實這邊是沒有真正內容的。

不過實際上，這邊真的要跑測試的話，也會有一個問題就是，要怎麼把 build 階段建置出來的執行檔、傳遞到 test 階段了。

如果 build 和 test 使用的是同一台 runner 的話，其實問題不會太大，只要把 GIT_STRATEGY 也改成 none，他就不會去清理檔案了。

但是如果 runner 的數量夠多，那 test 可能會是和 build 不同的機器，理論上這時候應該就得透過 cache 的機制來做不同 job 之間的檔案傳遞，不過 Heresy 這部分就還沒有認真玩出來就是了。

.gitlab-ci.yml 這個 script 的內容大概也就是這樣了。當然 .gitlab-ci.yml 其實還有相當多的功能可以使用，不過實際上有的還得搭配付費版的 GitLab 才能使用，所以在撰寫的時候也得注意一下版本了。

另外，在 GitLab Runner 的部分，由於 Heresy 這邊是用 VM 來運作，所以在設定上和一般開發環境的架設差不多，重點就是要把對應的軟體、工具都裝好、讓他能建置專案了。