GitLab CIで連続pushしたときに先行ジョブを中断する

コードベース＆開発チームが大きくなると、ビルドにかかる時間も、ビルドが始まるまでの待ち時間もどんどん長くなっていきます。お金を積んでGitLab Runnerを増強してしまえれば一番早いですが、この文書では小手先のテクニックでビルドキューに少しでも空きを作る方法を紹介します。

確認環境

• GitLab.com (12.7.0-pre 94b8fd8d152)

背景

次のように自動テストを実行する test ステージと、デプロイを実行する deploy ステージからなるビルドパイプラインを構築しているとします。

.gitlab-ci.yml

image: busybox:latest

stages:
  - test
  - deploy

frontend-test:
  stage: test
  script:
    - echo "frontend-test ..."
    - sleep 10

backend-test:
  stage: test
  script:
    - echo "backend-test ..."
    - sleep 10

deploy:
  stage: deploy
  script: "echo deploying..."

この作業ブランチを GitLab に push すると、自動的にビルドが開始されます。ここまでは期待通りですが、ここで修正ミスに気付くなどして、まだビルドが終わっていない状態で再度コードを push するとします。すると、1回目の push に対するビルドとは別に、もう1つ新たにビルドパイプラインが開始されてしまいます（下図参照）

一般に、静的解析や自動テストは最新のコミットに対する実行結果だけがあれば十分なケースが多く、連続して push した場合には先行ジョブのビルドを続ける意味がありません。そのための GitLab Runner のリソースを別のジョブに割り当てた方が有意義といえます。

解決策

GitLab には、中断可能（interruptible）なジョブを指定する機能があるため、これを使います。デフォルトでは、interruptible = false です。

.gitlab-ci.yml

image: busybox:latest

stages:
  - test
  - deploy

frontend-test:
  stage: test
  script:
    - echo "frontend-test ..."
    - sleep 10
+ interruptible: true

backend-test:
  stage: test
  script:
    - echo "backend-test ..."
    - sleep 10
+ interruptible: true

deploy:
  stage: deploy
  script: "echo deploying..."

interruptible = true を指定した状態でコードを連続 push すると、下図のように先行するパイプラインのジョブが自動的に中断され、canceled ステータスになるのが分かります。ただし、ドキュメントにも記載がある通り、1つでも interruptible = false なジョブの実行が開始されてしまうと、そのパイプラインはもう中断できません。

なお、先行ジョブを中断するかどうかはブランチ単位で管理されるため、下図のように異なるブランチで並行 push してもどちらかのパイプラインが中断されるわけではありません。

参考

• GitLab CI/CD Pipeline Configuration Reference | GitLab