CIのre-runとは? 解説

re-runは、失敗の後に、その失敗が再発しないかもしれないという前提で、CIのjob、ステップ、またはworkflow全体を再び実行します。

「失敗したjobを再実行する」ボタンは、CIで最もクリックされる機能の1つであり、その頻度自体が1つのシグナルです。re-runは自動retryの手動版のいとこです。一時的な障害に対しては有用ですが、反射的に使うと本当の問題を隠す松葉杖になります。

re-runがすること

re-runは失敗した作業を最初からやり直します。プラットフォームによって、1つの失敗したjobだけ、workflow内の失敗したjobだけ、あるいはすべてを再実行できます。テスト対象のコードは変わりません。失敗が本当にはコードのせいではなかったと賭けているのです。

手動 vs 自動

手動のre-runは、赤いbuildの後に人がボタンをクリックすることです。自動のre-run(retry)は介入なしで起こります。どちらも一時的な障害に役立ちますが、人によるre-runはコンテキストスイッチと遅延のコストもかかり、それこそが自動retryが取り除くコストです。

re-runが正当なとき

失敗が一時的だったと信じる十分な理由があるとき、re-runは妥当です。ログに残るネットワークタイムアウト、registryの503、負荷のかかったrunnerでのout-of-memory kill などです。同じjobを再び実行すれば、本当に合格する可能性が高いのです。

問題を隠すとき

すべての赤いbuildを反射的にre-runするのは危険な兆候です。re-runがフレーキーテストを「直す」なら、そのテストは依然として壊れており、先延ばしにしただけです。そして決定的な失敗をre-runが合格させることは決してないため、それらのre-runは分を浪費するだけです。頻繁なre-runは、flakinessを常態化させるのではなく、測定して修正すべき合図です。

Latchkeyの観点

Latchkeyの自己修復するマネージドrunnerは、正当な一時的障害のre-runを自動のものに変えます。検出された一時的または機械的な問題でjobが失敗すると、runnerがそれをretryするため、一度きりのblipがbuildを失敗させず、手動のクリックとコンテキストスイッチを取り除きます。

重要なポイント

re-runは、失敗したjob、workflow、またはステップを再び実行します。
手動のre-runは人にコンテキストスイッチのコストをかけ、自動のものはそうしません。
re-runは一時的な障害に対しては正当です。
反射的なre-runはフレーキーテストや本当の問題を隠します。