iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 6
0
DevOps

用 GitLab CI 玩轉自動化測試與佈署系列 第 6

Day06 - GitLab CI 變數還可以怎麼定義?再談 GitLab 各層級變數

上一篇提到了基本 .gitlab-ci.yml 上設定變數的方法,系統已經存在的預存環境變數,也初步提到從外部傳入變數的方法,那麼,在 GitLab CI 中,還有哪些傳入變數的方案呢?

GitLab CI 定義的各種層級變數

在 GitLab CI 的官方手冊中,關於環境變數 (environment variables) 的定義總共提到「12 種」,分別是:

  1. 觸發變數(Trigger variables)
    觸發變數主要使用在當欲使用 GitLab API 啟用流水線工作時,可以傳入工作的變數。
  2. 流水線排程變數(scheduled pipeline variables)
    在 GitLab 的介面中,可以針對已經存在的流水線設定排程,定期執行,在定義排程的時候也可以連帶定義該排程啟用時的要輸入的變數。
  3. 手動啟動流水線變數manual pipeline run variables
    如上一篇在介紹手動啟動流水線時,有提到透過選單 CI/CD -> Pipeline 的介面中,可以手動啟動流水線,這部分也可以設定變數。
  4. 專案階層變數(Project-level variables)
    在「專案」的設定(settings) 選單 -> CI/CD 中,展開「Variables」,這邊可以設定專案階層的變數。
  5. 組織/群組階層變數(Group-level variables)
    在「組織/群組」的設定(settings) 選單 -> CI/CD 中,展開「Variables」,這邊可以設定「組織/群組」階層的變數。
  6. GitLab 系統層變數(Instance-level variables)
    在自己架設的 GitLab (self-host)環境中, 也可以設定 GitLab Server 階層的變數,其在**管理者介面(Admin area)中的設定(settings) **選單 -> CI/CD 中,展開「Variables」,這邊可以設定 GitLab 系統層級的變數,這功能是在 GitLab 13.0 之後才提供的。
  7. 工作繼承變數(Inherited environment variables)
    工作繼承變數主要用在工作與工作之間的變數傳遞,可以用在前一個工作完成後,定義一個變數,傳遞到下一個需要此變數的工作中繼續使用。這是一個比較特別的變數,待底下更詳細的介紹。
  8. .gitlab-ci.yml 定義之工作變數(YAML-defined job-level variables)
    .gitlab-ci.yml 的各個工作中定義 variables 的變數
  9. .gitlab-ci.yml 定義之全域變數(YAML-defined global variables)
    .gitlab-ci.ymldefault 工作中定義 variables 的變數
  10. 部署環境變數(Deployment variables)
    於部署的環境設置變數,這個變數比較常見的使用場景如 Kubernets 的環境變數
  11. 系統預定義變數(Predefined environment variables)
    系統預載的環境變數,其 GitLab 預設提供的環境變數清單如此連結
  12. Runner Server 定義之 Runner 環境變數
    在設定 GitLab Runner Server 時,可以在 [[runners]] 區段的部分,設定「environment」定義環境變數。

工作繼承變數(Inherited environment variables)

當有些情境會需要在第一個工作進行過程中定義好變數,供給後續的工作使用,這時候就可以使用到「工作繼承變數」,要啟用工作繼承變數主要是利用後續會更詳細介紹的 artifacts 功能「reports:dotenv」的功能,在第一個工作產生的變數,建立一個 .env 檔案而產出「.env 成品」(artifact)後,透過工作與工作間的「相依」功能或 DAG 會介紹到的「需要」功能 傳送到下一個工作。

如 GitLab 手冊上介紹「工作繼承變數」的兩個範例,其一透過相依的流水線執行結果,及透過需要的流水線執行結果。兩個範例中,均為在 build 工作中,將 BUILD_VERSION 這個變數及其對應的數值輸出到 build.env 檔案中並將及設定為工作成品(artifact),並透過「相依」或「需要」功能傳遞到下一工作。

重覆定義的變數該聽誰的?

在 GitLab 官方手冊上是這樣規劃的

  1. 觸發變數(Trigger variables)、流水線排程變數(scheduled pipeline variables) 以及手動啟動流水線變數manual pipeline run variables
  2. 專案階層變數(Project-level variables)
  3. 組織/群組階層變數(Group-level variables)
  4. GitLab 系統層變數(Instance-level variables)
  5. 工作繼承變數(Inherited environment variables)
  6. .gitlab-ci.yml 定義之工作變數(YAML-defined job-level variables)
  7. .gitlab-ci.yml 定義之全域變數(YAML-defined global variables)
  8. 部署環境變數(Deployment variables)
  9. 系統預定義變數(Predefined environment variables)

上述的順序即是變數重複定義時的優先權定義,排序數字越小的優先權越高,舉例來說,如果在「手動啟用流水線」定義變數 PREFIX_VARHi 在「.gitlab-ci.yml 」中定義工作變數 PREFIX_VARHello,那麼在工作中 script 使用到 PREFIX_VAR 這個變數時,他的值會是 Hi,因為手動啟用流水線設定之變數在第一層,其優先權是最高的。

如 Day05 中的範例,系統原本定義 PREFIX_VAR 變數內容為 Hello,但透過手動執行流水線輸入 Hi,其輸出結果即改變為輸出 Hi
手動執行 Pipeline 流水線執行畫面

另外,第一階層的三種變數,因為都是在啟動流水線使用的,因此不可能同時被定義,因此歸屬在同一個優先權階層。

手冊上沒提到的 Runner Server 定義之變數屬於哪個優先權層級?

如下圖,在 GitLab Runner Server 的 config.toml 定義了 [[runner]] 區段的 environment 變數,RUNNER_VAR01CI_JOB_URL 等變數。

runner variable 01

目前實際的實驗結果,其屬於第 10. 階層的,也就是說當與 GitLab 手冊上定義的變數重複時,均會被覆寫掉

runner variable 02 覆寫結果

搭配變數覆寫優先權後各個變數的使用場景

可以發現在 GitLab 的系統中,大部分變數的設置範圍優先權越低的變數,其可以使用的範圍越大,如 .gitlab-ci.ymldefault 中定義的 variables 變數,可以供整個 .gitlab-ci.yml 中的所有工作使用,但如在各自的工作中再次定義variables 變數,即能覆蓋掉 default 區段中定義的變數。

因此定義變數時,可以思考,這個「變數」的使用範圍,如「大部分」是整個群組都可以使用的,那麼就可以思考將之定義在群組範圍中,如僅是單一工作中會使用到,則也僅需要將其定義在單一工作中即可。

總結

在這篇中,總共提到 12 種定義變數的方法,也提到了各個層級定義的環境變數覆寫的優先層級,這部分可以供再次的思考,在設計專案工作流程流水線時,環境變數應該要定義在哪個層級比較適合。

接下來,將繼續往工作流程工作與工作間彼此的關聯討論。我是墨嗓(陳佑竹),期待這系列的文章能夠讓人有些幫助。


上一篇
Day05 - GitLab CI 怎麼從外帶入參數到流水線中?談 GitLab 的變數 variable
下一篇
Day07 - GitLab CI 如何在工作中打包?談產出工作成品 artifact
系列文
用 GitLab CI 玩轉自動化測試與佈署31

尚未有邦友留言

立即登入留言