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

<ph type="x-smartling-placeholder"></ph> 問題を報告する <ph type="x-smartling-placeholder"></ph> ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

このページでは、Bazel を使用したプログラムのビルド方法、ビルドコマンドの構文、 ターゲット パターンの構文。

クイックスタート

Bazel を実行するには、ベース workspace ディレクトリに移動します。 または「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 buildbazel 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 では、ビルドするターゲットをさまざまな方法で指定できます。総称して これらはターゲット パターンと呼ばれます。この構文は、次のようなコマンドで使用されます。 buildtest、または query

これに対して、labels を使用すると、 ターゲット(BUILD ファイルで依存関係を宣言するなど)、Bazel のターゲット パターンで複数のターゲットを指定します。ターゲット パターンは、トレーニング データの ワイルドカードを使用して、ターゲットのセットのラベル構文。最も単純なケースでは 有効なラベルも有効なターゲット パターンで、 あります。

// で始まるターゲット パターンはすべて、現在の できます。

//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 次と同等です。 <ph type="x-smartling-placeholder">
    </ph>
  • 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/...packages に対するワイルドカードで、すべてのパッケージを再帰的に指定します。 foo ディレクトリの下(パッケージ パスのすべてのルート)に配置します。:allターゲットに対するワイルドカード。パッケージ内のすべてのルールに一致します。この 2 つは foo/...:all のように組み合わせられます。両方のワイルドカードを使用する場合は、 foo/... と省略されます。

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

これは、:*:allスーパーセットであることを示すことを意味します。潜在的に 混乱を招くため、この構文ではおなじみの :all ワイルドカードを _deploy.jar などのビルド ターゲットは望ましくない一般的なビルド。

さらに、Bazel では、 ラベル構文。これは、多くの場合、Bash ファイル名の展開を使用するときに便利です。 たとえば、foo/bar/wiz//foo/bar:wiz と同等です( パッケージ foo/bar)または //foo:bar/wiz(パッケージ foo がある場合)に移動します。

多くの Bazel コマンドはターゲット パターンのリストを引数として受け取ります。 接頭辞否定演算子 - に従います。これを使用して、一連の 上記の引数で指定されたセットからターゲットを 1 つ作成します。これは 順序が重要です。次に例を示します。

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

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

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

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

ただし、この方法で目標値を引き算しても、 ターゲットの依存関係の可能性があるため、ビルドされないことを保証する 減らされなかった割合ですたとえば、ターゲット //foo:all-apis があるとします。 //foo/bar:api に依存する場合、後者は次のようにビルドされます。 構築の一部になります

tags = ["manual"] が指定されたターゲットは、ワイルドカード ターゲット パターンに含まれません。 (...:*:all など)になります。 bazel buildbazel test(ただし、 除外ワイルドカードのターゲット パターンが除外されます。つまり、それらのターゲット パターンは差し引かれます。すべきこと コマンドラインで明示的なターゲット パターンを使用して、 Bazel でビルド/テストしたい場合に使用します。一方、bazel query は実行されません。 フィルタリングが自動的に行われ、 bazel query)。

外部依存関係の取得

デフォルトでは、Bazel はプロジェクト中に外部依存関係をダウンロードしてシンボリック リンクします。 構築できます。しかし、これは望ましくない場合があります。たとえば、 新しい外部依存関係が追加されたときや、外部依存関係の追加を 「プリフェッチ」(たとえば、オフラインになるフライト前など)。もし ビルド中に新しい依存関係が追加されないようにするには、 --fetch=false フラグを指定できます。このフラグは リポジトリ ルールのうち、ローカル ディレクトリのディレクトリを 表示されます。local_repository への変更など。 new_local_repository と Android SDK および NDK リポジトリ ルール 値は --fetch の値に関係なく常に有効になります。

ビルド中に取得を禁止し、Bazel が新しい外部 IP アドレスを検出した場合 依存関係があると、ビルドは失敗します。

bazel fetch を実行すると、依存関係を手動で取得できます。条件 ビルド中に許可しない場合は、bazel fetch を実行する必要があります。

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

実行後は、MODULE.bazel になるまで再度実行する必要はありません。 おすすめします。

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

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

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

bazel fetch //...

Bazel 7 以降で Bzlmod を有効にしている場合は、 外部依存関係に

bazel fetch

利用できるツールがすべて揃っていれば、bazel 取得を実行する必要は一切ありません。 を使用して(ライブラリ JAR から JDK 自体に)をワークスペースのルートで参照します。 ただし、Workspace ディレクトリ以外で使用している場合は、Bazel による 実行前に bazel fetch が自動的に実行されます bazel build

リポジトリ キャッシュ

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

キャッシュがヒットするたびに、キャッシュ内のファイルの変更時刻が 更新しました。これにより、キャッシュ ディレクトリ内のファイルが最後に使用された際に、 キャッシュを手動でクリーンアップするなど 選択できますキャッシュが 自動的にクリーンアップされます。 アップストリームに より詳しくなる場合があります

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

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

ディストリビューション ディレクトリも、不要な Bazel を回避するメカニズムの一つです。 ダウンロードされます。Bazel は、リポジトリ キャッシュの前にディストリビューション ディレクトリを検索します。 主な違いは配布ディレクトリには手動の 学習しました。

--distdir=/path/to-directory 追加の読み取り専用ディレクトリを指定して、 取得するのではなくそのようなディレクトリからファイル名が は URL のベース名と同じで、さらにファイルのハッシュが ダウンロード リクエストで指定された値と同じである必要があります。この方法は、 ファイル ハッシュはリポジトリ ルールの宣言で指定します。

ファイル名の条件は正確性に必須ではありませんが、 候補ファイルの数を、指定したディレクトリごとに 1 つに減らします。この 配布ファイルのディレクトリを指定するのは、 そのようなディレクトリ内のファイルの数が大きくなります。

エアギャップのある環境での Bazel の実行

Bazel のバイナリサイズを小さくするために、Bazel の暗黙的な依存関係が取得されます ネットワーク経由でアクセスします。これらの暗黙的な依存関係は、 すべての人にとって必要ではない可能性があるツールチェーンやルールが含まれています。対象 たとえば、Android ツールはバンドルされておらず、Android のビルド時にのみ取得されます。 できます。

ただし、こうした暗黙的な依存関係により、Bazel をローカルマシンで実行する場合に問題が発生する すべての外部エンドポイントをベンダリングしている場合でも、 確認します。この問題を解決するには、リポジトリ キャッシュを準備します(Bazel 7 または またはディストリビューション ディレクトリ(7 より前の Bazel を使用)でこれらを含む 依存してから、Compute Engine インスタンスに オフラインのアプローチで クローズドな環境に移行しました

リポジトリ キャッシュ(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"

また、kubectl の「get」コマンドや ローカルで 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"

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

bazel build @additional_distfiles//:archives.tar

この tarball を、エアギャップのあるディレクトリにコピーできるディレクトリにエクスポートします。 できます。--strip-components フラグに注意してください。--distdir は、 ディレクトリのネスト レベルについては、かなり複雑です。

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 Kubernetes Engine の 構成として環境データをまとめます。

1 つのビルドに複数の構成が存在する場合があります。検討すべき事項 クロスコンパイル(64 ビット用の //foo:bin 実行可能ファイルをビルドします) ワークステーションは 32 ビットマシンです。ビルドによって 64 ビットを作成できるツールチェーンを使用して //foo:bin をビルドする必要がある 実行時に使用するさまざまなツールをビルドシステムで構築する必要もあります。 たとえば、ソースからビルドされ、その後にツールが これらはワークステーションで実行するように構築する必要があります。したがって 2 つの構成を識別できます。exec 構成は、 ビルド中に実行するツールをビルドするためのターゲット構成リクエスト構成でもかまいませんが、「ターゲット構成」と呼ぶこともあります。 その単語にはすでに多くの意味がありますが)に基づき、 バイナリが分割されます。

通常、リクエストされた両方の前提条件となるライブラリは多数あります。 ビルド ターゲット(//foo:bin)と 1 つ以上の実行ツール(例: 使用できます。このようなライブラリは、exec 用に 1 回、合計 2 回ビルドする必要があります。 ターゲット構成で 1 回です。Bazel がお客様のデータを 両方のバリアントがビルドされ、派生ファイルが保持されるようにします。 干渉を避けるために分離する。通常、このようなターゲットは同時にビルドできます。 これらは互いに独立しているからです進行状況に関するメッセージが表示される場合 特定のターゲットが 2 回ビルドされていることを示します。この場合、 説明します。

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

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

さまざまな理由から、個別の経営幹部を選択することをおすすめします。 取得されます。最も重要な点:

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

次に、すべてのビルドで exec 構成と request 構成を分離することで、 環境に小さな変更を加えることによる高コストの 構成(リンカー オプションの変更など)は、 挙げられます

増分再ビルドを修正

Bazel プロジェクトの主な目標の 1 つは、 構成されます。以前のビルドツール、特に Make をベースとしたビルドツールは、 思い込みが合わないという問題がありました。

まず、ファイルのタイムスタンプは単調に増加します。これは 一般的なケースでは、この前提から外れることはとても簡単です。同期先 そのファイルの変更時間が短くなる。 Make ベースのシステムは再構築されません。

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

また Make は、いずれかの Pod の停止に失敗しても堅牢ではありません。 そのサブプロセスが出力ファイルへの書き込みを開始した後、しばらく 現在の Make の実行が失敗すると、後続の Make の呼び出しは、 むやみに切り捨てられた出力ファイルが有効であると仮定する( 再ビルドされることはありません。同様に Make プロセスが 同様の状況が発生する可能性があります。

Bazel では、このような前提条件は回避されています。Bazel では、すべてのコンポーネントの 実行され、そのセットが検出された場合にのみビルドステップが省略されます。 そのビルドステップへの入力ファイルとそのタイムスタンプ、 データベース内の 1 つのコマンドと完全に一致し、かつ、そのビルドステップが データベース エントリの出力ファイルのセット(およびそのタイムスタンプ)が ディスク上のファイルのタイムスタンプです。入力ファイルまたは出力ファイルの変更 指定すると、ビルドステップが再実行されます。

適切な増分ビルドを利用するユーザーにとってのメリットは、 混同です。(また、make clean の使用によって発生する再ビルドの待機時間(必要な場合、またはプリエンプティブの場合)が短縮されます)。

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

出力ファイルが存在し、その内容が手順または ルールを作成できます。ソースファイルを編集すると、 ビルドは「不整合」と見なされ、次回の実行まで一貫性がない状態を保ちます。 ビルドツールが正常に完了します。この状況は「不安定」と表現されます。 不整合。これはあくまで一時的なものであり、整合性は ビルドツールを実行します

有害な別の種類の不整合があります。それは安定です。 不整合。ビルドが整合性のない安定した状態に達した場合は、 ビルドツールを正常に呼び出しても整合性は復元されません。つまり、 出力は正しくないままです安定版の不整合な状態 これが、Make や他のビルドツールのユーザーが make clean をタイプする主な理由です。 この方法でビルドツールに失敗したことが判明した場合(その後、復元する) 作成に多大な時間と労力がかかる可能性があります。

概念的には、一貫したビルドを実現する最も簡単な方法は、 すべてのビルドをクリーンビルドにします。 この方法は明らかに時間がかかりすぎて実用的ではありません(ただし、 ため、これを有効に活用するためには、ビルドツールで 整合性を損なうことなく増分ビルドを実行できます

増分依存関係を正しく分析するのは困難であり、前述のように、 他のビルドツールでは、ビルド中に不安定な状態の安定した状態を回避できていない 使用できます。これに対して、Bazel では次のことが保証されています。 編集を行わなかったビルドツールの呼び出しが成功した場合は、 整合性のある状態に維持されます。(期間中にソースファイルを編集すると、 Bazel は、ビルドの結果の一貫性を保証しません。 確認できます。ただし、次のビルドの結果が 復元力があります。)

すべての保証と同様に、注意点があります。既知の方法はいくつかあります。 安定した不整合状態になりますただし、 バグを意図的に探し出すことで生じる問題を調査し 増分依存関係分析ですが、Google が調査し、修正に向けて最善を尽くします。 通常または「妥当」な状態から生じる、一貫性のないすべての状態使用 ビルドツールを使用します。

Bazel と一貫性のない状態を検出した場合は、バグを報告してください。

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

Bazel ではサンドボックスを使用して、アクションが密閉型で実行され、 確認します。Bazel は、次のようなサンドボックスでスポーン(大まかに言うとアクション)を実行します。 ツールが機能を実行するために必要な最小限のファイルのみを含む。現在 サンドボックス化は、Linux 3.12 以降で CONFIG_USER_NS オプションを指定すると機能します また、macOS 10.11 以降でもあります。

システムがサンドボックス化をサポートしていない場合、Bazel は警告を出力する ビルドが密閉型であることを保証しているわけではなく、 ホストシステムに侵入します。この警告を無効にするには、 --ignore_unsupported_sandboxing フラグを Bazel に設定。

Google Kubernetes Engine(GKE)や Engine クラスタノードか Debian のどちらであるかにかかわらず、 セキュリティ設定のため、デフォルトで無効になります。 考えていますこれは、ファイルの内容と /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。 その場合は、属性で genrule のサンドボックスを無効にし、 --strategy=Genrule=standalone など、次の値を含むルールを --spawn_strategy=standalone。また、 Issue Tracker に送信し、使用している Linux ディストリビューションを明記してください。 今後のリリースで調査して修正を提供します

ビルドのフェーズ

Bazel では、ビルドは次の 3 つのフェーズで行われます。ユーザーとして認識し、 違いによって、ビルドを制御するオプションについての分析情報が得られます。 (下記をご覧ください)。

読み込みフェーズ

1 つ目は読み込みで、その間に必要なビルド ファイルがすべて 初期ターゲット、およびその依存関係の推移的なクロージャが読み込まれ、 キャッシュに保存されます

Bazel サーバー起動後の最初のビルドでは、通常、読み込みフェーズで ファイル システムから多くの BUILD ファイルが読み込まれるため、数秒で済みます。イン 後続のビルド(特に BUILD ファイルに変更がない場合)は読み込みが発生する あります。

このフェーズで報告されるエラーには、「package not found」、「target not found」、 BUILD ファイル内の語彙や文法の誤り、評価の誤りなど、

分析フェーズ

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

読み込みと同様に、分析全体を計算するときにも数秒かかります。 ただし、Bazel は、あるビルドから次のビルドまで依存関係グラフをキャッシュに保存します。 内容を再分析します。これにより、インクリメンタル ビルドを非常に速く 以前のビルドからパッケージが変更されていない場合は

この段階で報告されるエラーには、不適切な依存関係、無効などがあります。 ルール固有のエラー メッセージがすべて表示されます。

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

実施フェーズ

ビルドの 3 番目かつ最後のフェーズは実行です。このフェーズでは 各ステップの出力が入力と一致していることを確認し、 コンパイル / リンクなどツールが用意されています。このステップでは 数秒から大規模なイベントの場合は 1 時間以上に 構築できます。このフェーズで報告されるエラー: ソースファイルの欠落、エラー なんらかのビルド アクションによって実行されたツール、 出力のセットです。