CIにおける一時的な失敗とは？解説

一時的な失敗とは、一時的で環境的な状態によって引き起こされる失敗です。まったく同じjobを少し後に再実行すると成功します。

赤いbuildがすべてコードの問題を意味するわけではありません。CIの失敗の大部分は、jobそのものではなく、jobを取り巻く環境から生じます。不安定なネットワーク、過負荷のregistry、一瞬メモリ不足になったrunnerなどです。これらは一時的なものであり、正しい対応はコードの失敗とは根本的に異なります。

定義的な性質：リトライ可能であること

一時的な失敗とは、定義上、リトライで解消できるものです。入力は有効でコードも正しかったのに、環境内の一時的な状態が干渉しました。コードや設定に何も問題がないため、単にjobを再実行するだけで成功することがよくあります。

典型的な原因

ネットワークの瞬断：DNSの不調、切断された接続、TLSハンドシェイクのタイムアウト。
上流の負荷：package-registryのレート制限や5xxレスポンス。
リソースの枯渇：一時的なout-of-memory killやディスクフルの状態。
インフラ：spot-instanceのプリエンプションや、プロバイダーの短時間のインシデント。

なぜ重要なのか

一時的な失敗を本物の失敗として扱うと、そのたびに誰かがコンテキストスイッチ、調査、手動リトライのコストを負担します。さらに悪いことに、それはチームに赤いbuildを反射的に再実行するよう習慣づけ、本当に注意が必要な決定論的な失敗への反応を鈍らせます。

一時的 vs 決定論的

決定論的な失敗は、原因がコードや設定にあるため、jobを実行するたびに起こります。一時的な失敗は、原因が環境にあるため、時々起こります。最も有用な診断的な問いはこれです。信頼できる形で再現するか？もしそうなら決定論的であり、リトライは役に立ちません。

Latchkeyの視点

一時的か決定論的かを見分けることは、まさにLatchkeyの自己修復managed runnerが自動化することです。ネットワークの瞬断、registryのタイムアウト、out-of-memory killといった一時的および機械的な失敗を検出し、影響を受けたjobを自動的にリトライします。そのため一度きりの環境的な瞬断でbuildが失敗することはなく、本物のコードの失敗は依然として赤として表面化します。

重要なポイント

一時的な失敗は、一時的な環境状態によって引き起こされます。
リトライ可能です。同じjobを再実行すると成功します。
よくある原因はネットワーク、registry、リソース、インフラです。
一時的か決定論的かを見分けることが、信頼性の鍵となるスキルです。