BazelCon 2024 登録の受け付けを開始しました。

このページは Cloud Translation API によって翻訳されました。

Bazel を使用してプログラムをビルドする

7.3 · 7.2 · 7.1 · 7.0 · 6.5

このページでは、Bazel を使用してプログラムをビルドする方法、ビルドコマンドの構文、ターゲットパターンの構文について説明します。

クイックスタート

Bazel を実行するには、ベースのワークスペースディレクトリまたはそのサブディレクトリに移動して bazel と入力します。新しいワークスペースを作成する必要がある場合は、build をご覧ください。

bazel help
                             [Bazel release bazel version]
Usage: bazel command options ...

使用できるコマンド

analyze-profile: ビルドプロファイルデータを分析します。
aquery: 分析後のアクショングラフに対してクエリを実行します。
build: 指定したターゲットをビルドします。
canonicalize-flags: Bazel フラグを正規化します。
clean: 出力ファイルを削除し、必要に応じてサーバーを停止します。
cquery: 分析後の依存関係グラフクエリを実行します。
dump: Bazel サーバープロセスの内部状態をダンプします。
help: コマンドのヘルプまたはインデックスを出力します。
info: bazel サーバーに関するランタイム情報を表示します。
fetch: ターゲットのすべての外部依存関係を取得します。
mobile-install: モバイルデバイスにアプリをインストールします。
query: 依存関係グラフのクエリを実行します。
run: 指定されたターゲットを実行します。
shutdown: Bazel サーバーを停止します。
test: 指定されたテストターゲットをビルドして実行します。
version: Bazel のバージョン情報を出力します。

困ったときは

bazel help command: command のヘルプとオプションを出力します。
bazel helpstartup_options: Bazel をホストする JVM のオプション。
bazel helptarget-syntax: ターゲットの指定方法について説明します。
bazel help info-keys: info コマンドによって使用されるキーのリストを表示します。

bazel ツールは、コマンドと呼ばれる多くの機能を実行します。最もよく使用されるのは bazel build と bazel test です。bazel help を使用してオンラインヘルプメッセージを参照できます。

1 つのターゲットをビルドする

ビルドを開始する前に、ワークスペースが必要です。ワークスペースは、アプリケーションのビルドに必要なすべてのソースファイルを含むディレクトリツリーです。Bazel を使用すると、完全に読み取り専用のボリュームからビルドを実行できます。

Bazel でプログラムをビルドするには、bazel build と続けてビルドするターゲットを入力します。

bazel build //foo

//foo をビルドするコマンドを実行すると、次のような出力が表示されます。

INFO: Analyzed target //foo:foo (14 packages loaded, 48 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
  bazel-bin/foo/foo
INFO: Elapsed time: 9.905s, Critical Path: 3.25s
INFO: Build completed successfully, 6 total actions

まず、Bazel はターゲットの依存関係グラフ内のすべてのパッケージを読み込みます。これには、宣言された依存関係、ターゲットの BUILD ファイルに直接リストされるファイル、ターゲットの依存関係の BUILD ファイルにリストされる推移的依存関係が含まれます。すべての依存関係を特定した後、Bazel は依存関係の正確性を分析し、ビルドアクションを作成します。最後に、Bazel はコンパイラやビルドの他のツールを実行します。

ビルドの実行フェーズで、Bazel は進行状況メッセージを出力します。進行状況メッセージには、開始時の現在のビルドステップ（コンパイラやリンカーなど）と、完了したビルドアクションの合計数が表示されます。ビルドが開始されると、Bazel がアクショングラフ全体を検出すると、多くの場合、合計アクション数は増加しますが、数秒以内に安定します。

ビルドの終了時に、リクエストされたターゲット、正常にビルドされたかどうか、正常にビルドされた場合は出力ファイルの場所が Bazel によって出力されます。ビルドを実行するスクリプトはこの出力を確実に解析できます。詳細については、--show_result をご覧ください。

同じコマンドをもう一度入力すると、ビルドが大幅に速く終了します。

bazel build //foo
INFO: Analyzed target //foo:foo (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
  bazel-bin/foo/foo
INFO: Elapsed time: 0.144s, Critical Path: 0.00s
INFO: Build completed successfully, 1 total action

これはnull ビルドです。変更されていないため、再読み込みするパッケージも、実行するビルドステップもありません。「foo」またはその依存関係に変更が加えられた場合、Bazel は一部のビルドアクションを再実行するか、増分ビルドを完了します。

複数のターゲットのビルド

Bazel では、ビルドするターゲットを指定する方法がいくつかあります。これらを総称してターゲットパターンと呼びます。この構文は、build、test、query などのコマンドで使用されます。

ラベルは、BUILD ファイルで依存関係を宣言する場合など、個々のターゲットを指定するために使用されますが、Bazel のターゲットパターンは複数のターゲットを指定します。ターゲットパターンは、ワイルドカードを使用してターゲットのセットのラベル構文を一般化したものです。最も単純なケースでは、有効なラベルは有効なターゲットパターンでもあり、1 つのターゲットのセットを識別します。

// で始まるターゲットパターンはすべて、現在のワークスペースを基準に解決されます。

`//foo/bar:wiz`	単一のターゲット `//foo/bar:wiz` のみです。
`//foo/bar`	`//foo/bar:bar` と同じです。
`//foo/bar:all`	パッケージ `foo/bar` 内のすべてのルールターゲット。
`//foo/...`	ディレクトリ `foo` の下のすべてのパッケージ内のすべてのルールターゲット。
`//foo/...:all`	ディレクトリ `foo` の下のすべてのパッケージ内のすべてのルールターゲット。
`//foo/...:*`	ディレクトリ `foo` の下のすべてのパッケージ内のすべてのターゲット（ルールとファイル）。
`//foo/...:all-targets`	`foo` ディレクトリの下にあるすべてのパッケージ内のすべてのターゲット（ルールとファイル）。
`//...`	メインリポジトリのパッケージ内のすべてのルールターゲット。外部リポジトリのターゲットは含まれません。
`//:all`	ワークスペースのルートに BUILD ファイルがある場合、最上位パッケージ内のすべてのルールターゲット。

// で始まらないターゲットパターンは、現在の作業ディレクトリを基準に解決されます。次の例では、作業ディレクトリが foo であることを前提としています。

`:foo`	`//foo:foo` に相当します。
`bar:wiz`	`//foo/bar:wiz` と同じです。
`bar/wiz`	次と同等です。 `foo/bar/wiz` がパッケージの場合は `//foo/bar/wiz:wiz` `foo/bar` がパッケージの場合は `//foo/bar:wiz` それ以外の場合は `//foo:bar/wiz`
`bar:all`	`//foo/bar:all` に相当します。
`:all`	`//foo:all` に相当します。
`...:all`	`//foo/...:all` に相当します。
`...`	`//foo/...:all` に相当します。
`bar/...:all`	`//foo/bar/...:all` に相当します。

デフォルトでは、再帰ターゲットパターンに対してディレクトリシンボリックリンクが使用されます。ただし、ワークスペースのルートディレクトリに作成された便利なシンボリックリンクなど、出力ベースの下を指すリンクは除きます。

また、Bazel は、次のような名前のファイルを含むディレクトリで再帰ターゲットパターンを評価するときに、シンボリックリンクをたどりません。DONT_FOLLOW_SYMLINKS_WHEN_TRAVERSING_THIS_DIRECTORY_VIA_A_RECURSIVE_TARGET_PATTERN

foo/... はパッケージのワイルドカードで、ディレクトリ foo の下にあるすべてのパッケージを再帰的に指定します（パッケージパスのすべてのルートについて）。:all はターゲットに対するワイルドカードで、パッケージ内のすべてのルールに一致します。この 2 つは foo/...:all のように組み合わせることができます。両方のワイルドカードを使用する場合は、foo/... と省略できます。

また、:*（または :all-targets）は、一致したパッケージ内のすべてのターゲットに一致するワイルドカードです。これには、java_binary ルールに関連付けられた _deploy.jar ファイルなど、通常はルールによってビルドされないファイルも含まれます。

これは、:* が :all のスーパーセットを表すことを意味します。混乱を招く可能性がありますが、この構文では、_deploy.jar などのターゲットのビルドが不要な一般的なビルドに、使い慣れた :all ワイルドカードを使用できます。

さらに、Bazel では、ラベル構文で必要なコロンの代わりにスラッシュを使用できます。これは、Bash ファイル名の展開を使用する場合によく便利です。たとえば、foo/bar/wiz は //foo/bar:wiz（パッケージ foo/bar がある場合）または //foo:bar/wiz（パッケージ foo がある場合）と同じです。

多くの Bazel コマンドは、ターゲットパターンのリストを引数として受け入れます。これらのコマンドはすべて、接頭辞否定演算子 - を尊重します。これは、前の引数で指定されたセットからターゲットのセットを減算するために使用できます。順序が重要であることに注意してください。次に例を示します。

bazel build foo/... bar/...

は「foo の下のすべてのターゲットと bar の下のすべてのターゲットをビルド」を意味します。

bazel build -- foo/... -foo/bar/...

は、「foo/bar の下にあるターゲットを除く foo の下のすべてのターゲットをビルドする」ことを意味します。- で始まる後続の引数が追加オプションとして解釈されないようにするには、-- 引数が必要です。

ただし、このようにターゲットを除外しても、除外されたターゲットの依存関係である可能性があるため、ターゲットがビルドされないとは限りません。たとえば、//foo/bar:api に依存するターゲット //foo:all-apis がある場合、後者は前者のビルドの一部としてビルドされます。

tags = ["manual"] が指定されたターゲットは、bazel build や bazel test などのコマンドで指定された場合、ワイルドカードターゲットパターン（...、:*、:all など）に含まれません（ただし、負のワイルドカードターゲットパターンに含まれるため、ターゲットは差し引かれます）。Bazel でビルドまたはテストする場合は、コマンドラインで明示的なターゲットパターンを使用してこのようなテストターゲットを指定する必要があります。一方、bazel query はこのようなフィルタリングを自動的に実行しません（これにより、bazel query の目的が果たされません）。

外部依存関係のフェッチ

デフォルトでは、Bazel はビルド中に外部依存関係をダウンロードしてシンボリックリンクを行います。ただし、新しい外部依存関係が追加されたときを知りたい場合や、依存関係を「プリフェッチ」したい場合（オフラインになるフライトの前になど）は、この方法は望ましくありません。ビルド中に新しい依存関係が追加されないようにするには、--fetch=false フラグを指定します。このフラグは、ローカルファイルシステム内のディレクトリを参照しないリポジトリルールにのみ適用されます。local_repository、new_local_repository、Android SDK と NDK のリポジトリルールへの変更は、--fetch の値に関係なく常に有効になります。

ビルド中にフェッチを禁止し、Bazel が新しい外部依存関係を見つけると、ビルドは失敗します。

依存関係を手動で取得するには、bazel fetch を実行します。ビルド中のフェッチを禁止する場合は、bazel fetch を実行する必要があります。

初めてビルドする前に。
新しい外部依存関係を追加した後。

一度実行すると、MODULE.bazel ファイルが変更されるまで再度実行する必要はありません。

fetch は、依存関係をフェッチするターゲットのリストを受け取ります。たとえば、//foo:bar と //bar:baz のビルドに必要な依存関係が取得されます。

bazel fetch //foo:bar //bar:baz

ワークスペースのすべての外部依存関係を取得するには、次のコマンドを実行します。

bazel fetch //...

Bazel 7 以降で Bzlmod を有効にしている場合は、次のコマンドを実行してすべての外部依存関係を取得することもできます。

bazel fetch

使用しているすべてのツール（ライブラリ JAR から JDK 自体まで）がワークスペースのルートにある場合、bazel 取得を実行する必要はありません。ただし、ワークスペースディレクトリの外部で何かを使用している場合、Bazel は bazel build の実行前に bazel fetch を自動的に実行します。

リポジトリキャッシュ

Bazel は、同じファイルが別のワークスペースで必要な場合や、外部リポジトリの定義が変更されても同じファイルをダウンロードする必要がある場合でも、同じファイルを複数回取得することを回避しようとします。この場合、Bazel は、デフォルトで ~/.cache/bazel/_bazel_$USER/cache/repos/v1/ にあるリポジトリキャッシュにダウンロードしたすべてのファイルをキャッシュに保存します。ロケーションは --repository_cache オプションで変更できます。キャッシュは、すべてのワークスペースとインストールされている bazel のバージョンで共有されます。Bazel が正しいファイルのコピーがあることを認識している場合、つまり、ダウンロードリクエストに指定されたファイルの SHA256 サムがあり、そのハッシュを持つファイルがキャッシュにある場合、エントリはキャッシュから取得されます。したがって、外部ファイルごとにハッシュを指定することは、セキュリティの観点から優れているだけでなく、不要なダウンロードの回避にも役立ちます。

キャッシュヒットごとに、キャッシュ内のファイルの変更時間が更新されます。これにより、キャッシュディレクトリ内のファイルが最後に使用された場所を簡単に特定できます（キャッシュを手動でクリーンアップするなど）。キャッシュには、アップストリームで利用できなくなったファイルのコピーが含まれている可能性があるため、キャッシュは自動的にクリーンアップされません。

[非推奨] 配信ファイルのディレクトリ

非推奨: オフラインビルドを実現するには、リポジトリキャッシュを使用することをおすすめします。

ディストリビューションディレクトリは、不要なダウンロードを回避するためのもう 1 つの Bazel メカニズムです。Bazel は、リポジトリキャッシュの前にディストリビューションディレクトリを検索します。主な違いは、ディストリビューションディレクトリを手動で準備する必要があることです。

--distdir=/path/to-directory オプションを使用すると、読み取り専用のディレクトリを追加して、ファイルを取得するのではなく検索できます。ファイル名が URL のベース名と等しく、さらにファイルのハッシュがダウンロードリクエストで指定されたハッシュと等しい場合、そのようなディレクトリからファイルが取得されます。これは、リポジトリルールの宣言でファイルハッシュが指定されている場合にのみ機能します。

ファイル名の条件は正確性のために必要ありませんが、指定したディレクトリごとに候補ファイルの数を 1 つに減らすことができます。この方法では、そのようなディレクトリ内のファイル数が大きくなっても、ディストリビューションファイルディレクトリの指定は効率的です。

エアギャップ環境で Bazel を実行する

Bazel のバイナリサイズを小さく保つため、Bazel の暗黙的な依存関係は、初めて実行するときにネットワーク経由で取得されます。これらの暗黙的な依存関係には、すべてのユーザーに必要でないツールチェーンとルールが含まれています。たとえば、Android ツールは、Android プロジェクトのビルド時にのみバンドル解除され、フェッチされます。

ただし、これらの暗黙的な依存関係は、外部依存関係をすべてベンダー化しても、エアギャップ環境で Bazel を実行するときに問題を引き起こす可能性があります。この問題を解決するには、ネットワークアクセスが可能なマシン上に、これらの依存関係を含むリポジトリキャッシュ（Bazel 7 以降）またはディストリビューションディレクトリ（Bazel 7 より前）を準備し、オフラインでエアギャップのある環境に転送します。

リポジトリキャッシュ（Bazel 7 以降）

リポジトリキャッシュを準備するには、--repository_cache フラグを使用します。暗黙的な依存関係はリリースごとに異なる可能性があるため、新しい Bazel バイナリバージョンごとに 1 回行う必要があります。

エアギャップ環境の外部で依存関係を取得するには、まず空のワークスペースを作成します。

mkdir empty_workspace && cd empty_workspace
touch MODULE.bazel

組み込みの Bzlmod 依存関係を取得するには、次のコマンドを実行します。

bazel fetch --repository_cache="path/to/repository/cache"

引き続き以前の WORKSPACE ファイルを使用する場合は、組み込みの WORKSPACE 依存関係を取得するには、次のコマンドを実行します。

bazel sync --repository_cache="path/to/repository/cache"

最後に、エアギャップ環境で Bazel を使用する場合は、同じ --repository_cache フラグを渡します。便宜上、.bazelrc エントリとして追加できます。

common --repository_cache="path/to/repository/cache"

また、BCR をローカルにクローンを作成し、--registry フラグを使用してローカルコピーを参照し、Bazel がインターネット経由で BCR にアクセスしないようにする必要があります。.bazelrc に次の行を追加します。

common --registry="path/to/local/bcr/registry"

ディストリビューションディレクトリ（7 より前の Bazel を使用）

ディストリビューションディレクトリを準備するには、--distdir フラグを使用します。暗黙的な依存関係はリリースごとに異なる可能性があるため、新しい Bazel バイナリバージョンごとに 1 回行う必要があります。

エアギャップ環境の外部でこれらの依存関係をビルドするには、まず、適切なバージョンの Bazel ソースツリーをチェックアウトします。

git clone https://github.com/bazelbuild/bazel "$BAZEL_DIR"
cd "$BAZEL_DIR"
git checkout "$BAZEL_VERSION"

次に、その特定の Bazel バージョンの暗黙的なランタイム依存関係を含む tarball をビルドします。

bazel build @additional_distfiles//:archives.tar

この tarball を、エアギャップ環境にコピーできるディレクトリにエクスポートします。--distdir はディレクトリのネストレベルで非常に繊細な動作になる可能性があるため、--strip-components フラグに注意してください。

tar xvf bazel-bin/external/additional_distfiles/archives.tar \
  -C "$NEW_DIRECTORY" --strip-components=3

最後に、エアギャップ環境で Bazel を使用する場合は、ディレクトリを指す --distdir フラグを渡します。便宜上、.bazelrc エントリとして追加することもできます。

build --distdir=path/to/directory

ビルド構成とクロスコンパイル

特定のビルドの動作と結果を指定するすべての入力は、2 つの異なるカテゴリに分類できます。1 つ目の種類は、プロジェクトの BUILD ファイルに保存される固有の情報（ビルドルール、その属性の値、その推移的依存関係の完全なセット）です。2 つ目の種類は、ユーザーまたはビルドツールから提供される外部データまたは環境データです。ターゲットアーキテクチャの選択、コンパイルとリンクのオプション、その他のツールチェーン構成オプションが含まれます。Google では、一連の環境データを構成と呼んでいます。

1 つのビルドに複数の構成が存在する場合があります。クロスコンパイルについて考えてみましょう。64 ビットアーキテクチャ用の //foo:bin 実行ファイルをビルドしますが、ワークステーションは 32 ビットマシンです。ビルドでは、64 ビットの実行可能ファイルを作成できるツールチェーンを使用して //foo:bin をビルドする必要がありますが、ビルドシステムはビルド自体で使用されるさまざまなツール（ソースからビルドされ、その後 genrule などで使用されるツールなど）もビルドする必要があります。これらのツールは、ワークステーションで実行するようにビルドする必要があります。したがって、2 つの構成を特定できます。実行構成は、ビルド中に実行されるツールのビルドに使用されます。ターゲット構成（またはリクエスト構成。この言葉にはすでに多くの意味がありますが、より一般的には「ターゲット構成」と呼ばれます）は、最終的にリクエストされたバイナリのビルドに使用されます。

通常、リクエストされたビルドターゲット（//foo:bin）と 1 つ以上の実行ツール（一部のベースライブラリなど）の両方の前提条件となるライブラリが多数あります。このようなライブラリは、実行構成用とターゲット構成用に 2 回ビルドする必要があります。Bazel は、両方のバリアントがビルドされ、干渉を回避するために派生ファイルが分離されるようにします。通常、このようなターゲットは相互に独立しているため、同時にビルドできます。特定のターゲットが 2 回ビルドされていることを示す進行状況メッセージが表示された場合は、これが原因と思われます。

実行構成は、次のようにターゲット構成から派生します。

--host_crosstool_top が指定されていない限り、リクエスト構成で指定されているものと同じバージョンの Crosstool（--crosstool_top）を使用します。
--cpu には --host_cpu の値を使用します（デフォルト: k8）。
リクエスト構成で指定されている --compiler、--use_ijars と同じ値を使用します。--host_crosstool_top が使用されている場合、--host_cpu の値を使用して、exec 構成の Crosstool で default_toolchain を検索します（--compiler は無視されます）。
--javabase には --host_javabase の値を使用します。
--java_toolchain には --host_java_toolchain の値を使用します。
C++ コードに最適化されたビルドを使用する（-c opt）。
デバッグ情報を生成しない（--copt=-g0）。
実行可能ファイルと共有ライブラリからデバッグ情報を削除します（--strip=always）。
すべての派生ファイルを、可能なリクエスト構成で使用される場所とは異なる特別な場所に配置します。
ビルドデータによるバイナリのスタンプ付けを抑制します（--embed_* オプションを参照）。
他の値はすべてデフォルトのままにします。

リクエスト構成から明確な実行構成を選択する理由はいくつかあります。最も重要な点は次のとおりです。

まず、削除された最適化済みバイナリを使用すると、ツールのリンクと実行にかかる時間、ツールが占有するディスク容量、分散ビルドでのネットワーク I/O 時間が短縮されます。

2 つ目は、すべてのビルドで実行構成とリクエスト構成を分離することで、前述のようにリクエスト構成に軽微な変更（リンカーオプションの変更など）を加えた場合に発生する、非常に費用のかかる再ビルドを回避できることです。

増分再ビルドを修正する

Bazel プロジェクトの主な目標の 1 つは、正しい増分再ビルドを確実に行うことです。以前のビルドツール（特に Make ベースのツール）は、増分ビルドの実装でいくつかの安全でない前提条件を想定しています。

まず、ファイルのタイムスタンプは単調に増加します。これは一般的なケースですが、この前提に違反することは非常に簡単です。ファイルの以前のリビジョンと同期すると、そのファイルの変更時間が短縮され、Make ベースのシステムは再ビルドされません。

より一般的に、Make はファイルの変更を検出しますが、コマンドの変更は検出しません。特定のビルドステップでコンパイラに渡されるオプションを変更した場合、Make はコンパイラを再実行しません。make clean を使用して、前のビルドの無効な出力を手動で破棄する必要があります。

また、Make は、サブプロセスが出力ファイルへの書き込みを開始した後に、そのサブプロセスのいずれかが正常に終了しなかった場合に堅牢ではありません。現在の Make の実行は失敗しますが、その後の Make の呼び出しでは、切り捨てられた出力ファイルが有効であると盲目的に想定され（入力ファイルよりも新しいため）、再ビルドされません。同様に、Make プロセスが強制終了された場合も同様の状況が発生する可能性があります。

Bazel では、このような前提条件を回避します。Bazel は、以前に行われたすべての作業のデータベースを維持します。ビルドステップの入力ファイルのセット（およびそのタイムスタンプ）と、そのビルドステップのコンパイルコマンドがデータベース内の 1 つと完全に一致し、データベースエントリの出力ファイルのセット（およびそのタイムスタンプ）がディスク上のファイルのタイムスタンプと完全に一致する場合にのみ、ビルドステップを省略します。入力ファイルや出力ファイル、あるいはコマンド自体を変更すると、ビルドステップが再実行されます。

正しい増分ビルドを使用すると、混乱して無駄な時間が減るというメリットがあります。（また、make clean の使用による再ビルドの待ち時間が短縮されます。これは、再ビルドが必要な場合でも、先行型の場合でも同様です）。

ビルドの整合性と増分ビルド

形式的には、必要な出力ファイルがすべて存在し、そのファイルの作成に必要なステップまたはルールで指定されている内容が正しければ、ビルドの状態を「整合性」と定義します。ソースファイルを編集すると、ビルドの状態は不整合になります。この状態は、次にビルドツールを実行して正常に完了するまで続きます。この状況は一時的なもので、ビルドツールを実行すると整合性が復元されるため、不安定な不整合と呼ばれます。

有害な不整合には、安定した不整合という別の種類もあります。ビルドが安定した不整合状態に達すると、ビルドツールを繰り返し正常に呼び出しても整合性が復元されません。ビルドは「停止」し、出力は引き続き正しくありません。安定した不整合状態は、Make（および他のビルドツール）のユーザーが make clean を入力する主な理由です。ビルドツールがこのように失敗したことを検出して復元するには、時間がかかり、非常に面倒な作業になる可能性があります。

概念的には、一貫したビルドを実現する最も簡単な方法は、以前のビルド出力をすべて破棄して最初からやり直すことです。つまり、すべてのビルドをクリーンビルドにします。このアプローチは、（リリースエンジニアを除き）明らかに時間がかかりすぎるため実用的ではありません。そのため、有用であるためには、ビルドツールが整合性を損なうことなく増分ビルドを実行できる必要があります。

正しい増分依存関係分析は困難です。前述のように、他の多くのビルドツールは、増分ビルド中に安定した不整合状態を回避するのに適していません。一方、Bazel では、編集を加えずにビルドツールを正常に呼び出した後、ビルドが一貫した状態になることが保証されます。（ビルド中にソースファイルを編集した場合、Bazel は現在のビルドの結果の一貫性を保証しません。ただし、次回のビルドの結果で整合性が復元されることは保証されます）。

他の保証と同様に、Bazel で安定した不整合状態になる方法がいくつか確認されています。増分依存関係分析でバグを意図的に見つけようとした結果生じる問題については、調査を保証するものではありませんが、ビルドツールの通常の使用または「合理的な」使用から生じる安定した不整合状態については、すべて調査し、修正するよう最善を尽くします。

Bazel で安定した不整合状態が検出された場合は、バグを報告してください。

サンドボックス化された実行

Bazel はサンドボックスを使用して、アクションが密閉状態で正しく実行されるようにします。Bazel は、ツールが機能を実行するために必要な最小限のファイルセットのみを含むサンドボックスでスポーン（大まかに言うとアクション）を実行します。現在、サンドボックス化は、CONFIG_USER_NS オプションが有効になっている Linux 3.12 以降と、macOS 10.11 以降で動作します。

システムがサンドボックス化をサポートしていない場合、Bazel は警告を表示し、ビルドが密閉型であるとは保証されず、ホストシステムに不明な点で影響を与える可能性があることを警告します。この警告を無効にするには、--ignore_unsupported_sandboxing フラグを Bazel に渡します。

Google Kubernetes Engine クラスタノードや Debian などの一部のプラットフォームでは、セキュリティ上の懸念から、ユーザー Namespace はデフォルトで無効になっています。これは、ファイル /proc/sys/kernel/unprivileged_userns_clone を確認することで確認できます。ファイルが存在し、0 が含まれている場合は、sudo sysctl kernel.unprivileged_userns_clone=1 でユーザー名前空間を有効にできます。

システムの設定が原因で、Bazel サンドボックスがルールを実行できないことがあります。この症状は通常、namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory のようなメッセージが出力される障害です。その場合は、--strategy=Genrule=standalone を使用して genrules と --spawn_strategy=standalone を使用する他のルールのサンドボックスを無効にしてみてください。また、Google が調査し、今後のリリースで修正できるように、Issue Tracker でバグを報告し、使用している Linux ディストリビューションもお知らせください。

ビルドのフェーズ

Bazel では、ビルドは 3 つの異なるフェーズで行われます。ユーザーはフェーズ間の違いを理解することで、ビルドを制御するオプションを詳細に分析できます（下記参照）。

読み込みフェーズ

1 つ目は読み込みです。このフェーズでは、初期ターゲットに必要なすべての BUILD ファイルと、それらの依存関係の推移閉包が読み込まれ、解析、評価、キャッシュに保存されます。

Bazel サーバーの起動後の最初のビルドでは、多くの BUILD ファイルがファイルシステムから読み込まれるため、通常、読み込みフェーズに数秒かかります。後続のビルドでは、特に BUILD ファイルが変更されていない場合は、読み込みが非常に高速に行われます。

このフェーズで報告されるエラーには、パッケージが見つからない、ターゲットが見つからない、BUILD ファイルの語彙や文法のエラー、評価エラーなどがあります。

分析フェーズ

2 つ目のフェーズである分析では、各ビルドルールのセマンティック分析と検証、ビルド依存関係グラフの構築、ビルドの各ステップで行う作業を正確に決定します。

読み込みと同様に、分析全体を計算する場合にも数秒かかります。ただし、Bazel はビルド間で依存関係グラフをキャッシュに保存し、必要なもののみを再分析します。これにより、パッケージが前回のビルドから変更されていない場合は、増分ビルドを非常に高速に行うことができます。

このステージで報告されるエラーには、不適切な依存関係、ルールへの無効な入力、ルール固有のエラーメッセージが含まれます。

この段階で Bazel は不要なファイル I/O を回避し、実行する作業を決定するために BUILD ファイルのみを読み取るため、読み込みフェーズと分析フェーズが高速になります。これは意図的なものであり、Bazel は、読み込みフェーズの上に実装される Bazel の query コマンドなどの分析ツールの基盤として適しています。

実施フェーズ

ビルドの 3 番目かつ最後のフェーズは実行です。このフェーズでは、必要に応じてコンパイルツールやリンクツールなどを再実行し、ビルドの各ステップの出力が入力と一致するようにします。このステップでビルドの大部分の時間が費やされます。時間は、大規模なビルドの場合は数秒から 1 時間以上に及ぶことがあります。このフェーズで報告されるエラーには、ソースファイルがない、ビルドアクションによって実行されたツールのエラー、ツールが想定される出力セットを生成できなかったなどがあります。