在流水線的進行中，有些時候工作能否被執行，跟執行工作的環境是絕對相依的，以 GitLab.com 提供的免費 GitLab Runner 來說，通常承接工作的 runner 環境都在 GitLab 提供的 k8s 環境使用 docker+machine 建立而成。而，如果有些工作必須在特定的作業系統如 Windows 上才能執行呢，那應該怎麼指定呢？

使用 tags 指定特定的 runner 承接工作

在 GitLab CI 的工作定義裡，可以透過 tags 來指定「符合這些 tag (標籤) 的 runner」來承接工作，舉例來說：

job:
  tags:
    - docker

上面的這個工作描述，意思是說：指定 GitLab Runner 中 Runner 的 Tag 有標示 docker 的 runner 來承接工作。而以 GitLab Runner 的角度來思考，則是在詢問 Server 上有沒有可以執行的工作時，根據自身定義的 Tag ，依序在工作佇列中依據工作的標籤，來判斷是否可以承接下該工作。

所以 GitLab CI 工作上標註的 tags 就可以想像成是定義該工作「可被執行的環境規格」，而 GitLab Runner 上標註的 tags 就像是能力標籤「Runner 的技能證照」，因此 Runner 上標注的 Tags 可能可以很多個，但可以承接的工作所標註的 tags 必須自己都有，所謂門當戶對。接著再看一個例子：

job:
  tags:
    - windows
    - win10-2004

根據 tags 是在定義可被執行的環境規格，如上面的範例即定義著，這個工作必須要「同時」擁有 windows 及 win10-2004 兩個 Tag 的 GitLab Runner 才能承接此工作。而當定義的環境規格沒有 Runner 可以承接時，則該工作會持續顯示顯示為pending 及標注這條流水線卡住 stuck (如下圖)。

或在工作流程細節頁面中的畫面

所以當出現 stuck 的時候，就應該檢查一下，是否根本不存在可以執行卡住的工作的 Runner 或可以執行工作的 Runner 太少，導致工作持續的在等待而被 pending。

設定 runner 的工作標籤

檢查系統中可用的 GitLab Runner 可以透過 「Settings -> CI/CD -> Runners -> 點選 Expand」後看到目前該專案中可使用的 runner。

在專案中，有兩種 Runner，一種是專案本身自行擁有的 Runner，另外一種則是所謂「shared Runner」由 GitLab 系統或整個組織/群組共用的 GitLab Runner。在專案層級中，僅能設定專案本身擁有的 Runner。

在上面的圖示中即可以看到 GitLab 官方提供的 shared Runner 其實每個 Runner 都有
Runner 工作 Tag的設定有兩個時間點，一是在設定新的 Runner 時，在設定 Runner 的過程即會作一次 tag 的設置。

另一是連線完成後，可在系統介面上透過編輯，在介面中進行 tags 的設定。如下點選編輯的按鈕：

而後在介面中進行 tags 的編輯來調整 Runner 的 tags 標籤。

因此在註冊 Runner 時如果標註錯誤或 runner 的屬性有所變更，在介面上就可以做調整了。

總結：

GitLab CI 的 tags 元素，對於工作本身，可以說是「可被執行的環境規格」，而對 GitLab Runner 來說，Tags 標註，則像是「Runner 的技能認證」，Runner 可以有很多的技能，但也僅能承接本身會的技能的工作。

接下來，依然是關於 GitLab CI 設定上的小細節，我是墨嗓(陳佑竹)，期待這系列的文章能夠讓人有些幫助。