演講紀錄 - GitLab 13.0 到 14.3 版關於 CICD 設定的功能亮點

01 - 活動紀錄

• 活動方：GitLab Taipei User Group
• 名稱：GitLab 13.0 到 14.3 版關於 CICD 設定的功能亮點
• 基本介紹：

這份簡報主要是搭配 GitLab 10 週年活動的分享，針對 GitLab 13.0 ~ 14.3 其中的 GitLab CICD 設定檔新增功能及變更所做的亮點整理。

在 GitLab 13.0 ~ 14.3 的版本更新及變更中，橫跨了 17 個版本，其關於 CICD 的設定變更幅度非常的多，因此在整理之後，又再次過濾及挑選一次。

這次整理的亮點主要包誇五大方向，分別是 Pipeline Editor、Include、Reference、Parallel With Matrix 以及 Directed Acyclic Graph (DAG) 的 Needs 功能。

02 - GitLab CI/CD 設定檔 Pipeline Editor 線上編輯器

在 GitLab 13.8 版開始，GitLab 在介面上增加了 Pipeline 的編輯器，在這個編輯器上，除了可以做 CICD 設定檔的文字編輯外，也可以直接在編輯器上看到編輯後的 Pipeline 視覺化關卡規劃，更可以直接線上做語法檢查 (Lint)，甚至，如果有使用到 extends, include 等語法時，還可以透過最後一個「View merged YAML」來查看合併之後的語法。到了 14.1 版，也開始支援可以在編輯器上選擇要編輯 CICD 設定檔的專案分支。

有 Pipeline Editor 線上編輯器之後，大幅度的改善以往在 local 端透過編輯器撰寫後，還必須複製到線上透過 Lint 工具才能知道語法是否正確的繁瑣，因為這個功能的新增，也改變了我個人的開發流程。

03 - Include

在 GitLab CICD 設定檔的語法中 Include 是很早就提供的功能，只是早期必須要付費版本才能使用，直到 GitLab 11.4 版開始下放到了免費版，從此讓 GitLab 變得很好用，也讓團隊的共用變得很有可能。

在最初開放給免費版本的 Include 語法中，包含四種格式，分別是 include:local:、include:remote、include:project 以及 include:template。

• include:local:：載入同專案中的其他 YAML 檔案，如果只有一個也可以直接簡短為 include: 'file-name.yml'
• include:remote：載入遠端公開路徑的 YAML 檔案
• include:project：載入其他專案中的 YAML 檔，可以透過 ref 設定是什麼分支以及透過 file 設定要載入的檔案路徑
• include:template：載入 GitLab 官方提供的 GitLab CICD Template

以上的功能在後續的版本中有一系列的變化，首先是載入其他專案的 YAML 檔，以往的語法一次只能載入一個專案中的一個檔案，在 13.6 之後開始，允許開發者在同一個專案宣告中，載入多個 YAML 檔案，範例語法如下：

1
2
3
4
5
6

include:
  - project: 'my-group/my-project'
    ref: main
    file:
      - '/template/.build.yml'
      - '/template/.tests.yml'

到了 13.8 以及 14.2 甚至開始提供在專案路徑上可以使用變數。這些變數可以是專案、群組甚至是 GitLab 服務層級。範例語法：

1
2
3

include:
  - project: '$CI_PROJECT_PATH'
    file: '.compliance-gitlab-ci.yml'

以往載入同專案底下的專案必須要一個一個的載入，到了 13.11 版本後，可以使用 wildcard 的特性如：

1
2

include: 'configs/*.yml'
include: 'configs/**/*.yml'

到了 14.2 版之後，開始提供可以針對同專案底下的 include 撰寫 rules 條件語法，透過條件來決定要不要載入，如：

1
2
3
4
5
6
7
8

include:
  - local: builds.yml
    rules:
      - if: '$INCLUDE_BUILDS == "true"'

test:
  stage: test
  script: exit 0

04 - !reference tags 重複使用

以為，提供重複使用的語法僅有 include、extends 以及 anchors 語法，在 GitLab 13.9 之後，提供了 !reference tags 的語法工載入特定工作中的特定內容，如底下的範例：

1
2
3
4
5

# setup.yml

.setup:
    script:
      - echo creating environment

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# .gitlab-ci.yml

include:
  - local: setup.yml

.teardown:
  after_script:
    - echo deleting environment

test:
  script:
    - !reference [.setup, script]
    - echo running my own command
  after_script:
    - !reference [.teardown, after_script]

以上的 !reference 語法，經過 GitLab 的語法解析之後，會轉變為：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# .gitlab-ci.yml

.setup:
    script:
      - echo creating environment

.teardown:
  after_script:
    - echo deleting environment

test:
  script:
    - echo creating environment
    - echo running my own command
  after_script:
    - echo deleting environment

其中需要特別注意到的地方是 test 的這個工作。script 及 after_script 兩個部分，除了同一份 yaml 檔案的重複使用外，連 include 進來的 yaml 也可以透過 !reference tags 進行重複使用。

到了 GitLab 14.3 版中，甚是也提供了 rules 條件式的重複使用。

05 - Parallel With Matrix

parallel 語法是在 GitLab 11.5 版本中提供的，其讓工作可以透過平行化處理加快工作完成的時間，但並不是大部分的工作都可以支援平行化，因此對於大部分的使用者來說，幫助似乎不大。但到了 13.3 的版本，開始提供 parallel:matrix 工作，這個支援就讓很多只是變數不一樣的工作得以更加的精簡，如下的範例：

1
2
3
4
5
6
7
8
9
10
11

deploystacks:
  stage: deploy
  stript:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2

如上一個工作，在 GitLab 解析之後就可以變成三個工作，其三個工作的變數分別是為：

• PROVIDER: aws, STACK: monitoring
• PROVIDER: aws, STACK: app1
• PROVIDER: aws, STACK: app2

而到了 13.5 版，調整了規格變成可以支援一維陣列的支援。在到了 13.10 版本，則開始支援把 parallel:matrix 變數，帶到預計要 trigger 的工作中。

06 - Directed Acyclic Graph (DAG) 的 Needs 功能

Directed Acyclic Graph 中文通常被翻譯為「有向無環圖」，在 wiki 的解釋中是這樣說明的：在圖論中，如果一個有向圖從任意頂點出發無法經過若干條邊回到該點，則這個圖是一個有向無環圖。而在 GitLab 12.2 版本中開始支援 Pipeline 的有向無環圖，代表著 Pipeline 不必再一個一個關卡的進行，當一個工作完成，後續需要該工作完成後才能進行的工作可以直接開始進行。

以底下的範例中，設定結尾為 a 的個關卡工作，後續的工作都需要前面工作先完成，如 test_a 需要 build_a，test_b 需要 build_b：

在還沒有支援 DAG 的環境中，如過 Build 的這個關卡中，build_b 這個工作會執行的特別慢，則會導致 Test 關卡中的工作一直無法進行。

當有 DAG 的機制導入後，因為後續的工作可以直接開始進行，可能就會看到如上的範例，a 系列的工作一路執行到 Deploy 關卡了 build_b 工作還在進行。

這項特性，到了 GitLab 13.12 的 Pipeline 圖片中，讓 Pipeline 的檢視中，更加的有感覺，如下影片：

Stageless pipelines 14.2

GitLab 14.2 版中，提供了新的 Stageless pipelines 的特性，這可以讓 GitLab CICD 設定檔的內容更加的精簡，如下範例的變化：

以往必須要特別宣告 stage 才能更進行，現在透過 needs 的語法，只需要把需求相依設定好，也就可以進行了。

「GitLab 13.0 到 14.3 版關於 CICD 設定的功能亮點」簡報分享

簡報連結：GitLab 13~14CICD功能亮點提示-GitLab 10週年線上聚會 - Speaker Deck

結論：

GitLab 每個月的 22 日都會釋出一個版本，從 13.0 到 14.3 中共經歷了 17 次的釋出，期間新增的功能其實非常的多，在這次的簡報中，我取了其中我個人認為比較特別的特性，主要是可以幫助讓 GitLab CICD 設定檔的內容更加簡潔、更有重複使用性的特性，也希望這分享對於近期了解 GitLab CICD 的特性發展有幫助。

參考連結：

• Pipeline Editor | GitLab
• Keyword reference for the .gitlab-ci.yml file | GitLab