確定的な失敗とは何か？解説

確定的な失敗は、その原因が固定的で、環境のtransientな状態ではなく、コード、設定、または入力にあるため、実行のたびに発生します。

確定的な失敗は、逆説的ですが、良い種類の失敗です。再現可能であり、つまり調査して原因を突き止め、確信を持って修正できます。それを定義づける対比の相手はtransientな失敗であり、こちらは現れたり消えたりするため、リトライで対処するのが最善です。

それを定義づける性質: 再現可能であること

確定的な失敗は、同じ入力で同じjobを実行するたびに再現します。この一貫性こそが、それを診断可能にするものです。ローカルで再現し、bisectを行い、修正を検証できます。それが発生するかどうかに、環境が関与することは一切ありません。

典型的な原因

失敗するテストのassertion: コードが実際にテストの期待どおりに動作していない。
毎回まったく同じようにfailするコンパイルエラーや型エラー。
存在しないファイル、依存関係、または環境変数。
実行のたびに誤っている設定ミス。

リトライが役に立たない理由

確定的な失敗をリトライすることは、定義上、無意味です。同じ入力は同じ失敗を生み出すため、2回目の試行もまったく同じようにfailします。さらに悪いことに、リトライは数分を無駄にし、本当のシグナルを覆い隠してしまうことがあります。確定的な失敗は、すぐに、そしてはっきりとfailすべきです。

transientとの見分け方

単独で最も優れた診断材料は再現性です。失敗が実行のたびに再発するなら、それは確定的であり、修正が必要です。現れたり消えたりするなら、それはtransientであり、リトライが適切です。失敗を正しく分類することが、それをデバッグするのかリトライするのかを決めます。

Latchkeyの視点

Latchkeyの自己修復managed runnerは、設計上、慎重です。transientおよびメカニカルな失敗はリトライして、一度きりの不具合であなたのbuildをfailさせないようにしますが、確定的な失敗はすぐにfailさせます。なぜなら、本物のコードのバグをリトライしても、修正を遅らせるだけだからです。

重要なポイント

確定的な失敗は、同じ入力であれば実行のたびに再現します。
その原因は環境ではなく、コード、設定、または入力にあります。
リトライは役に立ちません。確定的な失敗はすぐにfailすべきです。
再現性が、transientか確定的かを見分ける鍵となるテストです。