フレーク bisect
不安定なテストは、ボット上で別のステップで報告されます（ビルド例）。
各テストログは、自動フレーク bisect をトリガーするための、以下のような事前に入力されたコマンドラインを提供します。
Trigger flake bisect on command line:
bb add v8/try.triggered/v8_flako -p 'to_revision="deadbeef"' -p 'test_name="MyTest"' ...
初めてフレーク bisect をトリガーする前に、ユーザーは google.com アカウントでログインする必要があります。
bb auth-login次に、提供されたコマンドを実行します。フレーク bisect を実行するビルドURLが返されます（例）。
運が良ければ、bisect は疑わしい箇所を指摘します。そうでない場合は、さらに読む必要があるかもしれません…
詳細な説明 #
技術的な詳細については、実装のトラッカーバグも参照してください。フレーク bisect アプローチは、finditと同じ意図を持っていますが、異なる実装を使用しています。
仕組み #
bisect ジョブには、キャリブレーション、逆方向および内側 bisect の 3 つのフェーズがあります。キャリブレーション中は、1 回の実行で十分なフレークが検出されるまで、合計タイムアウト（または繰り返し回数）を 2 倍にしてテストが繰り返されます。次に、逆方向 bisect は、フレークのないリビジョンが見つかるまで git の範囲を 2 倍にします。最後に、正常なリビジョンと最も古い不良リビジョンの範囲を bisect します。 bisect は新しいビルドプロダクトを生成せず、V8 の継続的なインフラストラクチャで以前に作成されたビルドのみに基づいていることに注意してください。
bisect が失敗する場合 #
- キャリブレーション中に信頼性が得られない。これは、百万回に一度のフレーク、または他のテストが並行して実行されている場合にのみ見られる不安定な動作（メモリを大量に消費するテストなど）で典型的です。
- 原因が古すぎる。 bisect は、一定のステップ数後、または古いビルドが分離サーバーで利用できなくなった場合に停止します。
- bisect ジョブ全体がタイムアウトする。この場合、古い既知の不良リビジョンを使用して再起動できる場合があります。
フレーク bisect をカスタマイズするためのプロパティ #
extra_args: V8 のrun-tests.pyスクリプトに渡される追加の引数。repetitions: テストの初期繰り返し回数（run-tests.pyの--random-seed-stress-countオプションに渡されます。total_timeout_secが使用されている場合は使用されません）。timeout_sec:run-tests.pyに渡されるタイムアウトパラメータ。to_revision: 不良であることがわかっているリビジョン。 bisect はここから開始されます。total_timeout_sec: bisect ステップ全体に対する初期合計タイムアウト。キャリブレーション中は、必要に応じてこの時間が数倍になります。無効にしてrepetitionsプロパティを使用するには、0 に設定します。variant:run-tests.pyに渡されるテストバリアントの名前。
変更する必要のないプロパティ #
bisect_buildername: bisect 用のビルドを生成したビルダーのマスター名。bisect_mastername: bisect 用のビルドを生成したビルダーの名前。build_config: V8 のrun-tests.pyスクリプトに渡されるビルド構成（パラメータ名は--mode、例：ReleaseまたはDebug）。isolated_name: 分離ファイルの名前（例：bot_default、mjsunit）。swarming_dimensions: テストを実行するボットのタイプを分類する Swarming ディメンション。文字列のリストとして渡され、それぞれname:valueの形式です。test_name: run-tests.py に渡される完全修飾テスト名。例：mjsunit/foobar。
ヒントとコツ #
ハングアップするテストの bisect（デッドロックなど） #
失敗した実行がタイムアウトし、パスが非常に高速に実行されている場合、timeout_sec パラメータを調整すると便利です。 bisect がハングアップした実行のタイムアウトを待つことで遅延されなくなります。たとえば、パスが通常 1 秒未満で到達する場合、タイムアウトを小さい値（たとえば 5 秒）に設定します。
容疑者に対する信頼度を高める #
実行によっては、信頼性が非常に低い場合があります。たとえば、1 回の実行で 4 つのフレークが見つかった場合、キャリブレーションは満たされます。 bisect 中は、1 つ以上のフレークを含むすべての実行は不良とみなされます。このような場合は、bisect ジョブを再起動し、to_revision を原因に設定し、元のジョブよりも多くの繰り返し回数または合計タイムアウトを使用して、同じ結論に再び到達することを確認すると便利です。
タイムアウトの問題の回避策 #
全体のタイムアウトオプションによってビルドがハングアップする場合、適切な繰り返し回数を推定し、total_timeout_sec を 0 に設定するのが最善です。
ランダムシードに依存するテストの動作 #
まれに、特定のランダムシードでのみコードパスがトリガーされる場合があります。この場合、extra_args を使用して修正すると効果的です。例："extra_args": ["--random-seed=123"]。そうでない場合、ストレステストランナーは全体で異なるランダムシードを使用します。ただし、特定のランダムシードは、あるリビジョンでは問題を再現する可能性がありますが、別のリビジョンでは再現しない可能性があることに注意してください。