iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 23
0
DevOps

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

Day23 - GitLab CI 新的流水線啟動,已經在執行的流水線工作是否停止?談 interruptible

有些時候,流水線(pipeline)上的系統部署、原始碼打包等工作,可能需要花費大量的時間或系統資源,因此,在這種資源或時間成本相對高的專案上,當流水線上還有工作還在進行時,同一 Git 分支又有新的 Commit 到來啟動流水線作業時,已經在線上的流水線作業,繼續執行與否?就是一個可以討論的議題了。

一、流水線執行中,同分支又一新的 commit 到來啟動新的流水線作業會發生什麼事?

在系統預設的情境中,在一個分支上,已經有一個流水線工作正在進行了,這時候同一分支有新的 Git Commit 到來,啟動新的流水線工作,這時候 GitLab Server 預設會保持新舊兩個流水線上的工作均繼續執行

如下圖,在 master 的分支上短時間內先後有兩個 Git Commit Push,則同一個分支上,兩個流水線工作同時進行。

同時執行流水線的畫面

二、該怎麼中斷已經在執行的流水線工作呢?

在 GitLab CI 中,可以使用 interruptible 參數,這個參數可以用來控制,當有新的流水線工作建立時,目前的這工作是否繼續執行。一般沒有設定的情境,其預設為 false,也就是不被中斷。舉例來說(以 GitLab 文件上的範例稍作修改):

stages:
  - stage1
  - stage2

step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
    - sleep 30
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "Can be canceled."
    - sleep 30
  interruptible: true

以上面的這例子,因為 interruptible 參數設定為 true 因此,當同一分支上有新的 Git Commit 到來建立新的流水線工作時,會立即中斷已經存在流水線上的工作,且後續的工作也均不再執行。如下圖,工作預計至少執行 30秒,但因為有新的流水線建立,其在 16 秒就被中斷了:

工作被中斷的畫面

三、如果流水線中有工作非一致設定為可中斷,那麼 GitLab 會如何執行?

當工作設定了 interruptible 參數為 true 時,新啟動的流水線工作會中斷已經存在的流水線工作,那麼,如不是所有的工作都設定了允許中斷,那流水線會怎麼進行?如底下的例子(取自 GitLab 官方文件,但增加 sleep,以方便操控新的流水線啟動),第二個工作未設定 interruptible,也就是預設為 false 不可被中斷。

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."
    - sleep 30

step-3:
  stage: stage3
  script:
    - echo "Because step-2 can not be canceled, this step will never be canceled, even though set as interruptible."
    - sleep 30
  interruptible: true

以上面的例子來說,因為第二個關卡中的工作未設定 interruptible 因此預設為 false,所以當工作執行到工作 step-2 時,如果有新的 commit 到來啟動流水線,將不再中斷目前的這條流水線。如下圖,舊的流水線將繼續執行。

舊的流水線將繼續執行 02

而,在 step-3 有重新設定了 interruptibletrue,這時候如果又再次有新的流水線啟動,依照 GitLab CI 的設計,因為 step-2 無法被中斷,所以連帶著 step-3 也不再被中斷,即使有設定interruptible。如下圖 step-3 已經執行了,此時啟動新的流水線工作,並不會中斷 step-3 的工作。

舊的流水線將繼續執行 03

另外,當工作在 Pending 狀態時,其系統會將該工作設定為可被中斷,不管是否有設定 interruptible 參數。

四、總結

是否允許新的流水線啟動中斷現行流水線工作,可能有幾個思考點:

  • 已經存在的流水線工作之產出物或執行結果是否有保留的必要?
  • 已經存在的流水線工作是否會搶佔到新流水線上工作的資源?如 GitLab Runner 資源、CPU 運算資源、運算時間資源等等
  • 已經存在的流水線工作,是否會影響到新的流水線工作執行?如部署動作可能因此新舊同時執行,導致非預期錯誤等。

接下來,即將進入玩轉 GitLab 系列的後半段,將會開始介紹關於 GitLab CI 設定的重構思考以及關於如何加速流水線的議題。我是墨嗓(陳佑竹),期待這系列的文章能夠讓人有些幫助。


上一篇
Day22 - GitLab CI 控制工作終止因素的各種方法,談 retry、timeout
下一篇
Day24 - GitLab CI 關於 GitLab Runner 的 Cache 快取設定及快取策略
系列文
用 GitLab CI 玩轉自動化測試與佈署31

尚未有邦友留言

立即登入留言