パイプラインのステータスとは? pass、fail、pendingの読み方

パイプラインのステータスは、runの全体的な結果であり、そのjobから success、failure、pending、cancelled のような状態へと集約されます。

pipelineをちらっと見るとき、ステータスは見出しを教えてくれます。合格したのか失敗したのか、それともまだ実行中なのか。その単一の値は、run内のすべてのjobのステータスから計算されます。ステータスは merge gate がチェックするもの、dashboardが要約するもの、通知が報告するものであり、それがどう集約されるかを理解することが重要です。

一般的なステータス値

pending または queued: 開始を待機中。
running または in progress: jobが実行中。
success または passed: すべての必須jobが成功。
failure または failed: 少なくとも1つの必須jobが失敗。
cancelled または skipped: 停止された、または未実行。

ステータスがどう集約されるか

runのステータスはそのjobから導出されます。すべての必須jobが成功すればrunは成功します。いずれかの必須jobが失敗すればrunは失敗します。オプションまたは allowed-to-fail とマークされたjobは、通常は全体のステータスを反転させません。

merge gateとしてのステータス

ブランチ保護は、pull requestがmergeできるようになる前にグリーンのステータスをしばしば要求します。だからこそ失敗したpipelineはmergeをブロックするのです。必須のstatus checkは、runが合格するまで満たされません。

簡単な例

pull requestで "All checks have passed"(緑)または "Some checks were not successful"(赤)が表示されます。クリックして進むとどのjobが失敗したかが分かり、関連するログへ直接飛べます。

ステータスとflakiness

ステータスは信頼できる場合にのみ意味を持ちます。ランダムに失敗するflakyなjobはステータスへの信頼を損ない、人々を赤のままmergeさせたり、闇雲に再実行させたりします。安定したrunnerと信頼できるretryがステータスを意味あるものに保ちます。マネージドrunner(Latchkey)は一時的なインフラ障害をretryするため、赤のステータスがより多くの場合に実際のコードの問題を反映します。

重要なポイント

パイプラインのステータスは、そのjobから集約されたrunの結果です。
必須のjobが失敗するとrunは失敗し、オプションのjobは通常そうなりません。
ブランチ保護はステータスをmerge gateとして使うため、flakinessがそれを損ないます。