設定を読んで、何が動くか答える

目標

.gitlab-ci.ymlはプログラムではなく宣言です。そのため「動かしてみればわかる」ではなく、読んで答えられなければなりません。パイプラインが想定と違う動きをする事故は、ほとんどすべてこのファイルの読み間違いで起きます。

ここではGitLabなしで、設定だけを見て答えを出します。

用意するもの

/opt/lab/glci/pipeline.yml   잡 다섯 개짜리 파이프라인
/opt/lab/glci/broken.yml     문법은 맞는데 뜻이 틀린 곳이 네 군데

mkdir -p /root/glci && cp /opt/lab/glci/* /root/glci/ && cd /root/glci

残すもの

01-jobs.txt     잡과 템플릿
02-vars.txt     같은 변수의 세 값
03-rules.txt    상황마다 도는 잡
04-broken.txt   틀린 네 군데와 고치는 법
fixed.yml       고친 파일
check.py        같은 실수를 다시 막는 검사
07-notes.md     왜 그런지

何がジョブで何がジョブでないか

pipeline.ymlで実際のジョブがいくつあり、名前が何かを01-jobs.txtに書き、.baseがなぜジョブではないのかを1行添えてください。

名前がドットで始まる項目は、隠されたテンプレートなので実行されません。extendsで取り込んで使うだけです。

stages・variablesのような予約語もジョブではありません。ジョブは5つです。

同じ名前の変数が3つ

RETRIESが3か所にあります。build・unit・lintそれぞれで実際に使われる値がいくつかを02-vars.txtに書き、なぜその値が勝つのかを1行書いてください。

グローバルのvariablesが最も弱く、テンプレート(.base)がその次で、ジョブ自身のvariablesが最も強いです。

buildとunitは.baseを継承するだけで、lintは自分の値を別に置いています。

いつ何が動くか

mainブランチへのプッシュ・マージリクエスト・タグの3つの状況それぞれで、どのジョブが動くかを03-rules.txtに書いてください。各状況は、その語(main・머지・태그)で始まる行で区切ります(韓国語の語2つは、順に「マージ」「タグ」を意味します)。

rulesは上から見ていき、最初に合ったところで止まります。何にも合わなければ、そのジョブは動きません。

when: neverだけがある最後の行が「それ以外では動かない」を意味します。

deploy-prodはタグでwhen: manualなので、パイプラインには現れますが、人が押さないと動きません。それも「動く」に入れ、手動だと書いてください。

文法は合っているのに意味が間違っている箇所

broken.ymlで4か所を見つけて04-broken.txtに書き、それぞれどう直すかも書いてください。

YAMLとしてはすべて読めます。間違っているのはGitLabのルールです。

• 1つのジョブがonlyとrulesを一緒に使えるでしょうか
• stagesにないステージを書くとどうなるでしょうか
• needsで後ろのステージのジョブを待てるでしょうか
• ステージの間でファイルを渡すのはcacheでしょうか、artifactsでしょうか

直してファイルに残す

4か所を実際に直したfixed.ymlを作ってください。ジョブは1つも減らしません。

直すときにジョブを消すと、検査は通りますがパイプラインの意味が変わってしまいます。やっていたことはそのままにして、書き方だけを直してください。

publishはcacheを消し、buildが作ったartifactsを受け取るようにします。同じパイプラインの中では前のステージのartifactsが自動で降りてくるので、絞り込みたいときだけdependenciesを書きます。

同じミスを機械に止めさせる

check.pyを作って、broken.ymlは止め、fixed.ymlは通してください。引数で受け取ったファイルを検査し、問題があれば0以外の値で終了します。

見るのは次の4つです。stagesにないステージ、only/exceptとrulesの併用、後ろのステージを待つneeds、そしてステージ間の受け渡しをcacheで行おうとしていることです。

止められない検査は検査ではなく、直したものまで止める検査は誰も使いません。2つのファイルで両方を確認してください。

次に読む人へ

ここで見たもののうち4つ以上を選んで07-notes.mdにまとめてください。何をしたかではなく、なぜそうなのかを書きます。

パイプラインが想定と違う動きをするときの自分が読むのだと考えてください。「rulesを見た」は役に立たず、「rulesは最初の一致で止まるので、下に書いた条件は上が合えば二度と見られない」は役に立ちます。