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


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

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

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

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

其中,三個階段大致上是:

  • 分析階段(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~2\MICROS~1\2017\BuildTools\VC\Auxiliary\Build\vcvars64.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 流程。

而接下來的 cppcheckbuild-windowstest-windowsbuild-linuxtest-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~2\MICROS~1\2017\BuildTools\VC\Auxiliary\Build\vcvars64.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-windowstest-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 來運作,所以在設定上和一般開發環境的架設差不多,重點就是要把對應的軟體、工具都裝好、讓他能建置專案了。

對「GitLab 簡單的 C++ 專案腳本範例」的想法

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.