上一篇提到了基本 .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.yml 的 default 工作中定義 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_VAR 為 Hi 在「.gitlab-ci.yml 」中定義工作變數 PREFIX_VAR 為 Hello，那麼在工作中 script 使用到 PREFIX_VAR 這個變數時，他的值會是 Hi，因為手動啟用流水線設定之變數在第一層，其優先權是最高的。

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

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

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

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

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

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

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

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

總結

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

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