Bazel フラグ クイック リファレンス

Bazel の膨大なコマンドライン フラグのリストを操作するのは簡単ではありません。このページでは、知っておくべき最も重要なフラグについて説明します。

ヒント: 表でフラグ名を選択すると、コマンドライン リファレンスのエントリに移動できます。

役立つ全般オプション

次のフラグは、コマンドラインで明示的に設定することを目的としています。

フラグ	説明
--config	.bazelrc ファイル内のフラグを、デバッグやリリースビルド用の構成など、構成に整理できます。追加の構成グループは --config=<group> で選択できます。
--keep_going	Bazel は、ビルドとテストの実行を可能な限り続行しようとします。デフォルトでは、Bazel は早期に失敗します。
--remote_download_outputs	リモート実行またはキャッシュ（ディスクとリモートの両方）を使用する場合は、次のように（中間）ビルド アーティファクトをすべてダウンロードすることを Bazel に通知できます。 --remote_download_outputs=all デフォルトでは、Bazel は最終バイナリなどのトップレベル アーティファクトと、ローカル アクションに必要な中間アーティファクトのみをダウンロードします。
--stamp	ビルド情報（ユーザー、タイムスタンプ）をバイナリに追加します。 注: これによりビルド時間が長くなるため、リリースビルド専用です。

ビルドとテストの問題を特定する

次のフラグは、Bazel のビルドエラーやテストエラーをよりよく理解するのに役立ちます。

フラグ	説明
--announce_rc	ユーザー定義、マシン定義、プロジェクト定義の .bazelrc ファイルによって暗黙的に設定されるフラグが表示されます。
--auto_output_filter	デフォルトでは、Bazel はログ スパムの発生を防ぐよう努め、コンパイラ ワーニングと、コマンドラインからリクエストされたパッケージとサブパッケージの Starlark デバッグ出力のみを表示します。すべてのフィルタを無効にするには、--auto_output_filter=none を設定します。
--sandbox_debug	サンドボックス化エラーを詳しく確認できます。Bazel がデフォルトでビルドをサンドボックス化する理由と、サンドボックス化される内容の詳細については、サンドボックス化のドキュメントをご覧ください。 ヒント: エラーの原因がサンドボックス化にあると思われる場合は、サンドボックス化を一時的にオフにしてみてください。 これを行うには、コマンドに --spawn_strategy=standalone を追加します。
--subcommands (-s)	ビルド中に Bazel が実行するすべてのコマンドの包括的なリストを表示します（成功または失敗に関係なく）。

起動

注意: 起動フラグはコマンドの前に渡して、サーバーの再起動をトリガーする必要があります。これらのフラグは慎重に切り替えてください。

フラグ	説明
--bazelrc	デフォルトの Bazel オプションは .bazelrc ファイルで指定できます。複数の .bazelrc ファイルが存在する場合は、--bazelrc=<path to the .bazelrc file> を追加して、使用する .bazelrc ファイルを選択できます。 ヒント: --bazelrc=dev/null は、.bazelrc ファイルの検索を無効にします。 これは、リリースビルドなど、クリーンなビルド環境を確保し、.bazelrc ファイルによる意図しない構成変更を防ぐ必要がある場合に最適です。
--host_jvm_args	Bazel サーバーが使用する RAM の量を制限します。たとえば、次のコマンドでは Bazel ヒープサイズを 3 GB に制限します。 --host_jvm_args=-Xmx3g 注: -Xmx は、Java 仮想マシン（JVM）の最大ヒープサイズの設定に使用されます。ヒープは、オブジェクトが割り当てられるメモリ領域です。このオプションの正しい形式は -Xmx<size> です。ここで、<size> は最大ヒープサイズで、次のような単位で指定します。 m: メガバイト g: ギガバイト k: キロバイト
--output_base	Bazel の出力ツリーを制御します。Bazel は、ログなどのビルド出力をソースツリー自体に保存しません。代わりに、この目的に別の出力ツリーを使用します。 ヒント: 1 つの Bazel ワークスペースで複数の出力ベースを使用すると、複数の Bazel サーバーを同時に実行できます。これは、分析スラッシングを回避する場合に役立ちます。詳細については、出力ベースの選択をご覧ください。

Bazel テスト

次のフラグは Bazel テストに関連しています。

フラグ	説明
--java_debug	Java テストが実行される前に、デバッガの接続を待機します。
--runs_per_test	テストを実行する回数。たとえば、テストを N 回実行するには、--runs_per_test=N を追加します。これは、不安定なテストをデバッグし、修正によってテストが常に合格するかどうかを確認するのに役立ちます。
--test_output	出力モードを指定します。デフォルトでは、Bazel はテスト出力をローカル ログファイルにキャプチャします。エラーのあるテストを反復処理する場合は、通常、--test_output=streamed を使用してテスト出力をリアルタイムで確認します。

Bazel 実行

次のフラグは Bazel の実行に関連しています。

フラグ	説明
--run_under	実行可能ファイルの呼び出し方法を変更します。たとえば、--run_under="strace -c" はデバッグによく使用されます。

ユーザー固有の bazelrc オプション

次のフラグは、ユーザー固有の .bazelrc オプションに関連しています。

フラグ	説明
--disk_cache	Bazel がアクションとアクション出力を読み書きできるディレクトリのパス。ディレクトリが存在しない場合は作成されます。コマンドに --disk_cache=<path> を追加すると、複数のブランチまたはワークスペース間でビルド アーティファクトを共有し、Bazel ビルドを高速化できます。
--jobs	実行する同時実行ジョブの数。これは通常、リモート実行を使用する場合にのみ必要です。リモート実行では、リモート ビルドクラスタがローカルのコア数よりも多くのジョブを実行します。
--local_resources	ローカルで実行されるアクションによって消費される CPU または RAM の量を制限します。 注: これは、分析やビルド オーケストレーションなどのタスクで Bazel サーバー自体が消費する CPU や RAM の量には影響しません。
--sandbox_base	サンドボックスがこのパスの下にサンドボックス ディレクトリを作成できるようにします。デフォルトでは、Bazel はローカル アクションをサンドボックス化された状態で実行します。これにより、ビルドにオーバーヘッドが追加されます。 ヒント: ビルドまたはテストに多くの入力ファイルがある場合は、tmpfs のパス（/run/shm など）を指定して、パフォーマンスを大幅に改善できます。

プロジェクト固有の bazelrc オプション

次のフラグは、プロジェクト固有の .bazelrc オプションに関連しています。

フラグ	説明
--flaky_test_attempts	テストが失敗した場合に、各テストを指定回数まで再試行します。これは継続的インテグレーションで特に役立ちます。合格に複数回の試行が必要なテストは、テストの概要で FLAKY とマークされます。
--remote_cache	キャッシュ エンドポイントの URI。リモート キャッシュを設定すると、Bazel ビルドを高速化できます。ローカル ディスク キャッシュと組み合わせることができます。
--remote_download_regex	--remote_download_outputs の設定に関係なく、パスがこのパターンに一致するリモートビルド出力を強制的にダウンロードします。このフラグを繰り返すことで、複数のパターンを指定できます。
--remote_executor	リモート実行エンドポイントの HOST または HOST:PORT。リモート実行サービスを使用している場合は、これを渡します。多くの場合、--remote_instance_name=<name> を追加する必要があります。
--remote_instance_name	リモート実行 API で instance_name として渡す値。
--show-timestamps	指定すると、Bazel によって生成された各メッセージに、メッセージが表示された時間を示すタイムスタンプが追加されます。これは、どのステップにどのくらいの時間がかかったかをすばやく把握するのに役立ちます。
--spawn_strategy	リモート実行でも、一部のビルド操作をローカルで実行するほうが速い場合があります。これは、ビルドクラスタの容量、ネットワーク速度、ネットワーク遅延などの要因によって異なります。 ヒント: ローカルとリモートの両方でアクションを実行し、より速い結果を受け入れるには、ビルドコマンドに --spawn_strategy=dynamic を追加します。