業務でGitLab CI/CD を使用しており、あまり見ないエラーを踏んだので紹介します。 <h2 id="h70120ab096">何をしようとしたか</h2> Schedule Pipeline で夜間に重たいリグレッションテストを実行しました。 あらかじめ定めたタイミングで、ソースコードをビルドしてテストすることにより、&nbsp;&nbsp; 品質を保証しようという狙いです。 詳しくは言えませんが、テストデータが膨大でどうしても時間はかかってしまうので、 スケジュール実行しようぜという方針になりました。 <h2 id="h5b604ce9b5">テスト内容についてもうちょっと詳しく</h2> スケジュール実行するパイプラインの内訳は、 平均して15分くらいかかるジョブ（テスト）を500ジョブ というものです（テスト同士の依存はない）。 GitLab CI/CDは分散実行可能なので、ジョブに対して適切な数の GitLab Runnder を用意してあげるのですが、 諸事情により GitLab Runner を2つしか用意できませんでした。 なので少なくとも2日はぶっ通しで動き続ける想定になります。なかなか鬼ですね。 2つのRunnerたち に対して少々の罪悪感を抱きつつも、パイプラインを起動して颯爽と退社しました。 <h3 id="hc9b75b8591">2日目</h3> 出社してGitLabのパイプライン画面から実行状況を確認、順調に進んでいるようです。ありがとう！ （"感謝よりRunnerを増やせ"という怒りの声が聞こえてきますが、無視です） <h3 id="hb123af4792">2日目定時</h3> 引き続きRunnerが順調にテストを捌いてくれています。 それをいいことに定時退社する気まんまんだった私のもとへ、1通のメールが届きます。 Your pipeline has failed. ...なんてこった！ <h2 id="h3e7d730a68">原因を調べてみる</h2> Your pipeline has failed. ということは文字通りパイプラインでエラーがあったよということなんですが、 テストがエラー扱いしたケース・異常終了となったケースどちらも該当します。 今回であれば、テストの量的に1日で終わるはずがないので、異常終了だと想定できます。 結果を確認しにいくと、 200/500 が成功していて、残り 300 が失敗していました。 失敗していたジョブに残されていたログは以下です。 There has been a timeout failure or the job got stuck. Check your timeout limits or try again ふむふむ、何やらタイムアウトされたらしいです。 ですが、そもそも失敗した 300 のジョブは時間的にまだ実行されていないはずで、 タイムアウトというのは少しおかしいですね。 There has been a timeout failure or the job got stuck. the job got stuck. で「スタックに入った」と言われていますが、これも少し違います。 GitLab CI/CD の仕様では、スタック状態になるのは 実行できるRunnerが見つからないとき です。 Runnerは2台しかないのでスタックに入るのは合っているのでは、と思うかもしれませんが、 実行できるRunnerが存在する場合は（タグとかで判定される）、Runnerが他ジョブを実行していたとしても、 スタック状態にはなりません。Pending（実行待ち） というステータスになります。 Check your timeout limits or try again タイムアウトは設定できますが、設定値はジョブ実行時に対してのものなので、 実行していないはずなのにタイムアウトになるのはやっぱりおかしいです。 <h2 id="h7a15e9a662">原因はGitLabだった</h2> 調べてもあまりヒットしないので、GitLabのソースをのぞいてみました。 すると、以下のようなそれっぽいコードを見つけます。 <code>BUILD_PENDING_OUTDATED_TIMEOUT = 1.day</code> <a href="https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/stuck_ci_jobs_worker.rb#L13" target="_blank" rel="noopener noreferrer">https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/stuck_ci_jobs_worker.rb#L13</a> どうやら、Pending 状態のまま24時間実行されない場合は、失敗として扱われるようです。 この値はソース上で定義してしまっているので外部からは変更できません。 いくつかの issue でも議論されていますが&nbsp;GitLab としては「CI のパフォーマンス全体にかかわるから」として、 設定値を外部に切り出すことはあまりしたくないようです。 <h2 id="h0e137bd3ce">原因はGitLabではない</h2> そもそも、3日もかかるようなパイプラインは不適切です。&nbsp;&nbsp; Runnerの数を調整して短縮すべきですし、Runnerが足りないならパイプライン自体を分割しましょう。 仕事で例えてみましょう（うまい例かどうかはわかりません）。 今回でいえば、2人の部下に72hかかる仕事を3日間徹夜でやらせようとしたようなイメージになります。 ヘルプを頼むか（Runnerを増やす）、1日の稼働時間を考慮して作業分割をしてあげるのは当然ですよね。 考えなしに仕事を押し付けたら、1日後に部下が体調不良で倒れた、みたいな状況だといえるでしょう。 （体調不良なので、やってないタスクがあっても続行不可ということです） なので、これは上司（パイプライン・Runnerの管理をするワタシ）が原因ということになりますね。

***

実行待ちが1日続くと失敗扱いになる、という閾値はドキュメントに書いておいて欲しい気はしますが、
パイプラインで重たい処理をさせようとした際は、Runnerをいたわる気持ちをもって設計を見直してみましょう！
（1ジョブの実行時間が長いのは処理内容上仕方ないケースもあると思うので、また別の話です）

PendingのJobは1日経つと失敗扱いになる

【GitLab】PendingのJobは1日経つと失敗扱いになる

mishio

<h2 id="he4bfbf1fe7">TL;DR</h2> ソースコードだけじゃなくて .gitlab-ci.yml もちゃんと構文チェックしようね、って話です。 （執筆時のGitLabのバージョンは 13系です） <h2 id="h6f05119469">.gitlab-ci.yml で構文エラーを起こすと...</h2> .gitlab-ci.yml は GitLab CI のパイプライン処理を定義するファイルです。 .yml なので、当然 yml の構文に従って書かないといけませんし、GitLab CI の構文にも沿ってないといけません。 構文をミスると、実行時に構文エラーという悲劇を招きます。 <img src="https://images.microcms-assets.io/assets/662af00d6f2f4f2eb4714bdc9fcdb3d1/a459f47968b54c9e86731f3d241378eb/ci-cd-commit-failure-yaml-invalid-pipeline-page.png" alt=""> さて、マージリクエスト時にビルドチェックを入れていたとしましょう チームの運用にもよりますが、以下のような対処法があるでしょう。 <ul><li>masterブランチに修正をマージして、リベースする</li><li>該当ブランチの yml を修正して一緒にマージする</li></ul> 前者はリベースの手間が発生し、後者はほかの人がマージを待つことになりますが、 それほど大きな対応ではなさそうです。 「yml なんてそんなに書かへんししゃーないね、次回から気をつけようね」 という声が聞こえてきそうですね。 <h2 id="hea0f61e37b">.gitlab-ci.yml を別リポジトリで管理していると...</h2> .gitlab-ci.yml は基本はリポジトリルートに置いて管理しますが、&nbsp;&nbsp; 設定でパスを変えることができます。 <a href="https://docs.gitlab.com/ee/ci/pipelines/settings.html#custom-ci-configuration-path" target="_blank" rel="noopener noreferrer">https://docs.gitlab.com/ee/ci/pipelines/settings.html#custom-ci-configuration-path</a> 別リポジトリに置くこともできて、CIでしか使わないスクリプトもひっくるめて別管理できたりします。 外部のymlファイルを参照した状態で構文エラーを起こした場合、 ymlファイルを修正してリトライするだけで問題なさそうなのですが、そう都合よくいきません。 パイプラインをリトライしても反映されない のです（実行時の環境でリトライなので当然ですが...）。 この場合のつらいところは、MRを出しなおすか再度プッシュするぐらいしか解決方法がないところです。 コードに修正箇所があればよいのですが、問題が何もないときは非常にストレスです。 <h2 id="h01e975a87a">修正時に構文解析をかけよう</h2> ソースコードの構文解析をCIでチェックする、というプロセスはよくありますよね。 同じように .gitlab-ci.yml も構文チェックしてあげましょう。 <h2 id="hdec97f7e7b">CI Lint</h2> GitLab には&nbsp;.gitlab-ci.yml の構文チェック機能があります。 <a href="https://docs.gitlab.com/ee/ci/lint.html" target="_blank" rel="noopener noreferrer">https://docs.gitlab.com/ee/ci/lint.html</a> ymlファイルの内容をコピペするだけです。簡単ですね。 マージリクエスト時にAPI 経由で構文解析をかける 「CI Lint を手動で実行する」という運用も悪くはないのですが、 CI Lint には APIが公開されているので、CIでCI Lint を実行しましょう。 以下サンプルです。 ※GitLabRunner の動作環境<ul><li>executer は shell (bash)</li><li>jq, curl が必要</li></ul> .gitlab-ci.yml<pre><code>stages:
&nbsp;- lint

CI_Lint:
&nbsp;stage: lint
&nbsp;only:
&nbsp;&nbsp;refs:
&nbsp;&nbsp;&nbsp;- merge_requests
&nbsp;script: &gt;
&nbsp;&nbsp;jq --null-input --arg yaml "$(&lt;.gitlab-ci.yml)" '.content=$yaml'
&nbsp;&nbsp;| curl 'http://your.gitlab.server/api/v4/ci/lint'
&nbsp;&nbsp;--header 'Content-Type: application/json'
&nbsp;&nbsp;--data @-
&nbsp;&nbsp;| test \$(jq --raw-output '.status') = "valid"; exit $?</code></pre> スクリプトについてはほぼ公式のコピペです <a href="https://docs.gitlab.com/ee/api/lint.html" target="_blank" rel="noopener noreferrer">https://docs.gitlab.com/ee/api/lint.html</a> <code>test $(jq --raw-output '.status') = "valid"; exit $?</code> 最後の部分で、APIのレスポンスをみて構文エラーがあれば失敗としています。 <h2 id="ha214098e44">まとめ</h2>これで、直接プッシュでもしないかぎりは、構文エラーの混入が防げるようになりました。 CI Lint のAPIなんてどこで使うねんと思っていましたが、思わぬところで活用できました。 .gitlab-ci.yml の構文エラーが多発して困っている方がいらっしゃれば、ぜひ参考にしてみてください。

【GitLab】CIファイルをCIでCI Lintにかける