這是我原先的.gitlab-ci.yml
stages:
- build
- deploy
- notify
build:
stage: build
script:
- echo "Compiling the code..."
deploy:
stage: deploy
needs:
- build
script:
- echo "Deploying application..."
when: manual
deploy-success:
stage: notify
needs: ["deploy"]
script:
- echo "is ok"
deploy-fail:
stage: notify
needs: ["deploy"]
script:
- echo "so bad"
when: on_failure
先build 後續需要人工觸發deploy
最後的 notify 取決於deploy成功與否印出不同訊息
整體流程如下圖
這邊有收到一個新需求 如果commit title 有包含'[auto]' 字樣
就讓他自動觸發 deploy
於是.gitlab-ci.yml 改成這樣
stages:
- build
- deploy
- notify
build:
stage: build
script:
- echo "Compiling the code..."
deploy:
stage: deploy
rules:
- if: '$CI_COMMIT_TITLE =~ /\[auto\]/'
- if: '$CI_COMMIT_TITLE !~ /\[auto\]/'
when: manual
needs:
- build
script:
- echo "Deploying application..."
deploy-success:
stage: notify
needs: ["deploy"]
script:
- echo "is ok"
deploy-fail:
stage: notify
needs: ["deploy"]
script:
- echo "so bad"
when: on_failure
我預期如果 commit title 不包含'[auto]'
他的流程應該會跟沒有改的時候一樣
但流程圖卻變成了這樣
notify的兩個job 狀態從原先的skipped 變成 created
想請教各位大神 為什麼使用 rules 添加 when
會出現這種不同的結果
這邊主要是因為 manual
的關係,而讓後續的工作狀態呈現 created
。
官方之前針對 needs
搭配 manual
的有寫了一篇文章,文章連結如下:
https://about.gitlab.com/blog/2021/05/20/dag-manual-fix/
我的認知是,這算是 GitLab 官方在設計 Pipeline 上每個工作狀態呈現以及 Pipeline 整體工作狀態呈現的「難題」呈現哪一種都對,也可能會有人認為不對。
當一個 Pipeline 中有一個手動工作,當 Pipeline 卡在這個手動工作上時,Pipeline 的狀態要呈現這個工作已完成?還是要呈現他被 blacked? 這邊在各個情境下會有不太一樣的需求。
因此有一個參數 allow_failure
來決定這件事情,當使用 manual 時,allow_failure 預設為 true,如果不想要他為 true,可特別加上參數 allow_failure: false
。當使用預設值時 allow_failure: true
後續的工作因為前一工作允許失敗,自然先建起來等,也就呈現狀態為 created
;而當 allow_failure: false
時,後續的工作必須等前面的工作確定有手動啟用,才建立,因此會先呈現 skipped
。