アクション
ビルド中に実行するコマンド。たとえば、アーティファクトを入力として受け取り、他のアーティファクトを出力として生成するコンパイラの呼び出しなどです。コマンドライン引数、アクションキー、環境変数、宣言された入力/出力アーティファクトなどのメタデータが含まれます。
関連情報: ルールに関するドキュメント
アクション キャッシュ
実行されたアクションと、それによって作成された出力のマッピングを保存するディスク上のキャッシュ。キャッシュキーはアクションキーと呼ばれます。Bazel の増分モデルのコア コンポーネント。キャッシュは出力ベース ディレクトリに保存されるため、Bazel サーバーの再起動後も保持されます。
アクション グラフ
アクションと、これらのアクションが読み取って生成するアーティファクトのインメモリ グラフ。グラフには、ソースファイルとして存在するアーティファクト（ファイル システムなど）と、BUILD ファイルに記載されていない生成された中間アーティファクトや最終アーティファクトが含まれる場合があります。分析フェーズで生成され、実行フェーズで使用されます。
アクション グラフクエリ（aquery）
ビルドのアクションに対してクエリを実行できるクエリツール。これにより、ビルドルールが実際のビルドの動作にどのように変換されるかを分析できます。
アクションキー
アクションのキャッシュキー。アクションのメタデータに基づいて計算されます。アクションによっては、アクションで実行されるコマンド、コンパイラ フラグ、ライブラリの場所、システム ヘッダーなどが含まれる場合があります。Bazel が個々のアクションを決定論的にキャッシュに保存したり、無効にしたりできるようにします。
分析フェーズ
ビルドの第 2 フェーズ。BUILD ファイルで指定されたターゲット グラフを処理して、実行フェーズで実行するアクションの順序を決定するインメモリのアクション グラフを生成します。これは、ルール実装が評価されるフェーズです。
アーティファクト
ソースファイルまたは生成されたファイル。ツリー アーティファクトと呼ばれるファイルのディレクトリにすることもできます。
アーティファクトは複数のアクションの入力になる可能性がありますが、生成できるのは最大で 1 つのアクションのみです。
ファイル ターゲットに対応するアーティファクトは、ラベルでアドレス指定できます。
Aspect
ルールが依存関係で追加のアクションを作成するためのメカニズム。たとえば、ターゲット A が B に依存している場合、依存関係エッジを B まで上にトラバースし、B で追加のアクションを実行して追加の出力ファイルを生成して収集するアスペクトを A に適用できます。これらの追加アクションは、同じアスペクト比を必要とするターゲット間でキャッシュに保存され、再利用されます。aspect() Starlark Build API 関数で作成されます。たとえば、IDE のメタデータを生成したり、lint 用のアクションを作成したりするために使用できます。
関連項目: アスペクトのドキュメント
アスペクト オン アスペクト
アスペクトを他のアスペクトの結果に適用できる合成メカニズム。たとえば、IDE で使用する情報を生成するアスペクトは、proto から .java ファイルを生成するアスペクトの上に適用できます。
アスペクト A をアスペクト B の上に適用するには、B が provides 属性でアドバタイズするプロバイダが、A が required_aspect_providers 属性で宣言する内容と一致する必要があります。
属性
ターゲットごとのビルド情報を表すために使用される、ルールのパラメータ。たとえば、srcs、deps、copts などがあります。これらはそれぞれ、ターゲットのソースファイル、依存関係、カスタム コンパイラ オプションを宣言します。特定のターゲットで使用できる属性は、そのルールタイプによって異なります。
.bazelrc
Bazel の構成ファイル。スタートアップ フラグとコマンド フラグのデフォルト値を変更し、--config フラグを使用して Bazel コマンドラインでまとめて設定できるオプションの共通グループを定義するために使用されます。Bazel は、複数の bazelrc ファイル（システム全体、ワークスペースごと、ユーザーごと、またはカスタムの場所）の設定を組み合わせることができます。また、bazelrc ファイルは他の bazelrc ファイルから設定をインポートすることもできます。
Blaze
Google 内部バージョンの Bazel。モノリポジトリ用の Google のメイン ビルドシステム。
BUILD ファイル
BUILD ファイルは、ビルドするソフトウェア出力、その依存関係、ビルド方法を Bazel に伝えるメインの構成ファイルです。Bazel は BUILD ファイルを入力として受け取り、そのファイルを使用して依存関係のグラフを作成し、中間ソフトウェアと最終ソフトウェアの出力をビルドするために完了する必要があるアクションを導出します。BUILD ファイルは、BUILD ファイルを含まないディレクトリとサブディレクトリをパッケージとしてマークし、ルールによって作成されたターゲットを含めることができます。ファイル名は BUILD.bazel にすることもできます。
BUILD.bazel ファイル
BUILD ファイルをご覧ください。同じディレクトリにある BUILD ファイルよりも優先されます。
.bzl ファイル
Starlark で記述されたルール、マクロ、定数を定義するファイル。これらは、load() 関数を使用して BUILD ファイルにインポートできます。
グラフを構築する
Bazel がビルドを実行するために構築してトラバースする依存関係グラフ。ターゲット、構成済みターゲット、アクション、アーティファクトなどのノードが含まれます。リクエストされたターゲットのセットが依存するすべてのアーティファクトが最新であると検証された場合、ビルドは完了したとみなされます。
ビルド設定
Starlark で定義された構成の一部。トランジションでは、ビルド設定を設定してサブグラフの構成を変更できます。コマンドライン フラグ（ビルドフラグとも呼ばれます）としてユーザーに公開されている場合。
クリーンビルド
以前のビルドの結果を使用しないビルド。通常、増分ビルドよりも遅くなりますが、一般的にはより正確であると考えられています。Bazel は、クリーンビルドと増分ビルドの両方が常に正しいことを保証します。
クライアント サーバー モデル
bazel コマンドライン クライアントは、ローカルマシンでバックグラウンド サーバーを自動的に起動し、Bazel コマンドを実行します。サーバーはコマンド間で永続化されますが、一定期間操作がないと自動的に停止します（または、bazel shutdown を使用して明示的に停止します）。Bazel をサーバーとクライアントに分割すると、JVM の起動時間を償却でき、アクション グラフがコマンド間でメモリに残るため、増分ビルドを高速化できます。
コマンド
コマンドラインで bazel
build、bazel test、bazel run、bazel query などのさまざまな Bazel 関数を呼び出すために使用されます。
コマンドフラグ
コマンドに固有のフラグのセット。コマンドフラグは、コマンド（bazel build <command flags>）の後に指定します。フラグは、1 つ以上のコマンドに適用できます。たとえば、--configure は bazel sync コマンド専用のフラグですが、--keep_going は sync、build、test などに適用できます。フラグは構成目的で使用されることが多いため、フラグ値の変更により、Bazel がインメモリ グラフを無効にして分析フェーズを再開することがあります。
構成
ルール定義の外部にある情報で、ルールがアクションを生成する方法に影響します。すべてのビルドには、ターゲット プラットフォーム、アクション環境変数、コマンドラインのビルドフラグを指定する構成が少なくとも 1 つあります。トランジションでは、ホストツールやクロス コンパイルなどの追加の構成が作成されることがあります。
関連項目: 構成
構成のトリミング
ターゲットが実際に必要とする構成の一部のみを含めるプロセス。たとえば、C++ 依存関係 //:c を使用して Java バイナリ //:j をビルドする場合、//:c の構成に --javacopt の値を含めるのは無駄です。--javacopt を不必要に変更すると、C++ ビルドのキャッシュ可能性が損なわれるためです。
構成済みクエリ（cquery）
構成されたターゲットに対してクエリを実行するクエリツール（分析フェーズの完了後）。つまり、select() とビルドフラグ（--platforms など）が結果に正確に反映されます。
関連情報: cquery のドキュメント
構成済みのターゲット
構成でターゲットを評価した結果。分析フェーズでは、ビルドのオプションとビルドする必要があるターゲットを組み合わせて、この値を生成します。たとえば、同じビルドで 2 つの異なるアーキテクチャの //:foo をビルドする場合、<//:foo, x86> と <//:foo, arm> の 2 つのターゲットが構成されます。
正確性
ビルドの出力が推移的な入力の状態を忠実に反映している場合、そのビルドは正しいと言えます。正しいビルドを実現するために、Bazel は密封性、再現性、ビルド分析とアクション実行の決定性を高めるよう努めています。
依存関係
2 つのターゲット間の有向エッジ。ターゲット //:foo の属性値に //:bar への参照が含まれている場合、ターゲット //:foo はターゲット //:bar に対するターゲット依存関係を持ちます。//:foo のアクションが //:bar のアクションによって作成された入力 アーティファクトに依存している場合、//:foo は //:bar とアクションの依存関係を持ちます。
Depset
推移的依存関係に関するデータを収集するためのデータ構造。依存関係セットの結合が時間と空間の効率を高めるように最適化されています。これは、非常に大きな依存関係セット（数十万のファイル）が一般的であるためです。スペース効率上の理由から、他の depsets を再帰的に参照するために実装されました。ルールの実装では、ビルドグラフの最上位にルールがない限り、depsset をリストに変換して「フラット化」してはなりません。大きな depsets をフラット化すると、メモリ消費量が大幅に増加します。Bazel の内部実装では、ネストされたセットとも呼ばれます。
関連情報: Depset のドキュメント
ディスク キャッシュ
リモート キャッシュ機能用のローカル ディスク上の blob ストア。実際のリモート blob ストアと組み合わせて使用できます。
Distdir
Bazel がリポジトリ ルールを使用してインターネットから取得するファイルを格納する読み取り専用ディレクトリ。ビルドを完全にオフラインで実行できるようにします。
動的実行
さまざまなヒューリスティックに基づいてローカル実行とリモート実行を選択し、より高速な成功したメソッドの実行結果を使用する実行戦略。特定のアクションはローカルで実行する方が速く（リンクなど）、他のアクションはリモートで実行する方が速くなります（高度に並列化可能なコンパイルなど）。動的実行戦略を使用すると、増分ビルドとクリーンビルドの時間を可能な限り短縮できます。
実施フェーズ
ビルドの第 3 フェーズ。分析フェーズで作成されたアクション グラフ内のアクションを実行します。これらのアクションは、実行可能ファイル（コンパイラ、スクリプト）を呼び出して、アーティファクトの読み取りと書き込みを行います。スポーン戦略は、これらのアクションがローカル、リモート、動的、サンドボックス、Docker などでどのように実行されるかを制御します。
実行ルート
ローカル アクションが非サンドボックス ビルドで実行される、ワークスペースの出力ベース ディレクトリ内のディレクトリ。ディレクトリの内容は、ワークスペースからの入力アーティファクトのシンボリック リンクがほとんどです。実行ルートには、他の入力としての外部リポジトリへのシンボリック リンクと、出力を保存する bazel-out ディレクトリも含まれています。読み込みフェーズで、ビルドが依存するパッケージの推移閉包を表すディレクトリのシンボリック リンクのフォレストを作成して準備されます。コマンドラインで bazel info
execution_root を使用してアクセスできます。
ファイル
アーティファクトをご覧ください。
密閉性
ビルドとテストのオペレーションに外部からの影響がない場合、ビルドは密閉型になります。これにより、結果が確定的で正しいことが保証されます。たとえば、密閉型ビルドでは通常、アクションへのネットワーク アクセスが禁止され、宣言された入力へのアクセスが制限され、固定のタイムスタンプとタイムゾーンが使用され、環境変数へのアクセスが制限され、乱数ジェネレータに固定シードが使用されます。
増分ビルド
増分ビルドでは、以前のビルドの結果を再利用して、ビルド時間とリソース使用量を削減します。依存関係のチェックとキャッシュ保存は、このタイプのビルドで正しい結果を生成することを目的としています。増分ビルドは、クリーンビルドの反対です。
ラベル
ターゲットの識別子。//path/to/package:target などの完全修飾ラベルは、ワークスペースのルート ディレクトリを示す //、ターゲットを宣言する BUILD ファイルを含むディレクトリとしての path/to/package、前述の BUILD ファイルで宣言されたターゲットの名前としての :target で構成されます。@my_repository//<..> を接頭辞として使用して、ターゲットが my_repository という名前の外部リポジトリで宣言されていることを示すこともできます。
読み込みフェーズ
Bazel が WORKSPACE、BUILD、.bzl ファイルを解析してパッケージを作成するビルドの最初のフェーズ。このフェーズでは、マクロと glob() などの特定の関数が評価されます。ビルドの第 2 フェーズ（分析フェーズ）とインターリーブして、ターゲット グラフを構築します。
マクロ
複数のルール ターゲット宣言を 1 つの Starlark 関数にまとめるメカニズム。BUILD ファイル間で共通のルール宣言パターンを再利用できるようにします。読み込みフェーズ中に、基盤となるルール ターゲット宣言に展開されます。
関連情報: マクロのドキュメント
ニーモニック
ルール作成者が選択した、人が読める短い文字列。ルールのアクションの内容をすばやく理解するために使用されます。ニーモニックは、スポーン戦略の選択の識別子として使用できます。アクションのニーモニックの例としては、Java ルールの Javac、C++ ルールの CppCompile、Android ルールの AndroidManifestMerger などがあります。
ネイティブ広告のルール
Bazel に組み込まれ、Java で実装されているルール。このようなルールは、.bzl ファイルでネイティブ モジュールの関数（native.cc_library や native.java_library など）として表示されます。ユーザー定義ルール（非ネイティブ）は Starlark を使用して作成されます。
出力ベース
Bazel 出力ファイルを保存するワークスペース固有のディレクトリ。ワークスペースのソースツリーから出力を分離するために使用されます。出力ユーザー ルートにあります。
出力グループ
Bazel がターゲットのビルドを完了したときにビルドされることが想定されるファイルのグループ。ルールは、通常の出力を「デフォルト出力グループ」に配置します（例: cc_library ターゲットの java_library、.a、.so の .jar ファイル）。デフォルトの出力グループは、コマンドラインでターゲットがリクエストされたときにアーティファクトがビルドされる出力グループです。ルールでは、BUILD ファイル（filegroup ルール）またはコマンドライン（--output_groups フラグ）で明示的に指定できる名前付き出力グループをさらに定義できます。
ユーザー root を出力する
Bazel の出力を保存するユーザー固有のディレクトリ。ディレクトリ名は、ユーザーのシステム ユーザー名から派生します。複数のユーザーがシステムで同じプロジェクトを同時にビルドしている場合に、出力ファイルの競合を防ぎます。個々のワークスペースのビルド出力に対応するサブディレクトリ（出力ベースとも呼ばれます）が含まれています。
パッケージ
BUILD ファイルで定義されたターゲットのセット。パッケージの名前は、ワークスペースのルートからの BUILD ファイルの相対パスです。パッケージには、サブパッケージや BUILD ファイルを含むサブディレクトリを含めることができ、パッケージ階層を形成します。
パッケージ グループ
パッケージのセットを表すターゲット。visibility 属性値でよく使用されます。
プラットフォーム
ビルドに関与する「マシンタイプ」。これには、Bazel が実行されるマシン（「ホスト」プラットフォーム）、ビルドツールが実行されるマシン（「実行」プラットフォーム）、ターゲットがビルドされるマシン（「ターゲット プラットフォーム」）が含まれます。
プロバイダ
依存関係に沿ってルール ターゲット間で渡す情報の単位を記述するスキーマ。通常、これにはコンパイラ オプション、推移的なソースファイルまたは出力ファイル、ビルド メタデータなどの情報が含まれます。depset と組み合わせて使用されることが多く、累積された推移的データを効率的に保存します。組み込みプロバイダの例として DefaultInfo があります。
関連情報: プロバイダのドキュメント
クエリ（コンセプト）
ビルドグラフを分析して、ターゲットのプロパティと依存関係の構造を理解するプロセス。Bazel は、query、cquery、aquery の 3 つのクエリ バリアントをサポートしています。
query（コマンド）
ビルドのポストローディング フェーズのターゲット グラフで動作するクエリツール。これは比較的高速ですが、select()、ビルドフラグ、アーティファクト、ビルドアクションの影響を分析できません。
関連項目: クエリの手順、クエリのリファレンス
リポジトリ キャッシュ
ビルド用に Bazel によってダウンロードされたファイルの共有コンテンツ アドレス指定可能キャッシュ。ワークスペース間で共有できます。初回ダウンロード後にオフライン ビルドを有効にします。通常、http_archive などのリポジトリ ルールや repository_ctx.download などのリポジトリ ルール API を介してダウンロードされたファイルをキャッシュに保存するために使用されます。ファイルは、ダウンロード用に SHA-256 チェックサムが指定されている場合にのみキャッシュに保存されます。
再現性
ビルドまたはテストのプロパティ。ビルドまたはテストへの一連の入力は、時間、メソッド、環境に関係なく、常に同じ一連の出力を生成します。これは、出力が正しい、または望ましい出力であることを必ずしも意味するものではありません。
ルール
BUILD ファイル（cc_library など）でルール ターゲットを定義するためのスキーマ。BUILD ファイルの作成者の視点から見ると、ルールは一連の属性とブラック ボックス ロジックで構成されます。このロジックは、出力 アーティファクトを生成し、他のルール ターゲットに情報を渡す方法をルール ターゲットに指示します。.bzl の作成者の観点から見ると、ルールは新しいプログラミング言語と環境をサポートするように Bazel を拡張する主な方法です。
ルールは、読み込みフェーズでルール ターゲットを生成するためにインスタンス化されます。分析フェーズのルールターゲットは、プロバイダの形式でダウンストリームの依存関係に情報を伝達し、出力アーティファクトの生成方法を記述するアクションを登録します。これらのアクションは、実行フェーズで実行されます。
関連情報: ルールに関するドキュメント
ルールのターゲット
ルールのインスタンスであるターゲット。ファイル ターゲットやパッケージ グループとは対照的です。ルールと混同しないようにしてください。
Runfiles
実行可能ターゲットのランタイム依存関係。通常、実行可能ファイルはテストルールの実行可能出力であり、runfile はテストのランタイム データ依存関係です。実行可能ファイルが呼び出される前（bazel test の実行中）、Bazel はソース ディレクトリ構造に従って、テスト実行可能ファイルとともにランファイル ツリーを準備します。
関連項目: Runfiles のドキュメント
サンドボックス化
実行中のアクションを制限された一時的な実行ルート内で分離する手法。これにより、宣言されていない入力の読み取りや宣言されていない出力の書き込みが行われないようにします。サンドボックス化は密閉性を大幅に向上させますが、通常はパフォーマンス コストが発生し、オペレーティング システムのサポートが必要になります。パフォーマンス コストはプラットフォームによって異なります。Linux では大きな問題ではありませんが、macOS ではサンドボックス化が使用できなくなる可能性があります。
Skyframe
Skyframe は、Bazel の並列、関数型、増分評価のコア フレームワークです。
スタンピング
追加情報を Bazel でビルドされたアーティファクトに埋め込む機能。たとえば、リリースビルドのソース管理、ビルド時間、その他のワークスペースまたは環境関連情報に使用できます。スタンプ属性をサポートする --workspace_status_command フラグとルールを使用して有効にします。
Starlark
ルールとマクロを記述するための拡張言語。構成とパフォーマンスの向上を目的とした、Python の制限付きサブセット（構文と文法）。.bzl ファイル拡張機能を使用します。BUILD ファイルは、以前は Skylark と呼ばれていた、さらに制限されたバージョンの Starlark（def 関数定義がないなど）を使用します。
関連情報: Starlark 言語のドキュメント
起動フラグ
bazel とコマンドの間に指定されたフラグのセット（例: bazel --host_jvm_debug build）。これらのフラグは Bazel サーバーの構成を変更するため、起動フラグを変更するとサーバーが再起動します。スタートアップ フラグは、特定のコマンドに固有のものではありません。
ターゲット
BUILD ファイルで定義され、ラベルで識別されるオブジェクト。ターゲットは、エンドユーザーの視点から見たワークスペースのビルド可能な単位を表します。
ルールをインスタンス化して宣言されたターゲットは、ルール ターゲットと呼ばれます。ルールによっては、実行可能（cc_binary など）またはテスト可能（cc_test など）な場合があります。通常、ルール ターゲットは、属性（deps など）を介して他のターゲットに依存します。これらの依存関係は、ターゲット グラフの基礎となります。
ルール ターゲットの他に、ファイル ターゲットとパッケージ グループ ターゲットもあります。ファイル ターゲットは、BUILD ファイル内で参照されるアーティファクトに対応します。特殊なケースとして、パッケージの BUILD ファイルは、常にそのパッケージのソースファイル ターゲットと見なされます。
ターゲットは読み込みフェーズで検出されます。分析フェーズでは、ターゲットはビルド構成に関連付けられて、構成済みターゲットを形成します。
ターゲット グラフ
ターゲットとその依存関係のインメモリ グラフ。読み込みフェーズで生成され、分析フェーズの入力として使用されます。
ターゲット パターン
コマンドラインでターゲットのグループを指定する方法。一般的に使用されるパターンは、:all（すべてのルール ターゲット）、:*（すべてのルール ターゲットとファイル ターゲット）、...（現在のパッケージとすべてのサブパッケージを再帰的に）です。たとえば、//...:* は、ワークスペースのルートから再帰的にすべてのパッケージ内のすべてのルールとファイル ターゲットを意味します。
テスト
ルール ターゲットはテストルールからインスタンス化されるため、テスト実行可能ファイルが含まれます。実行可能ファイルの完了から返されたゼロのリターンコードは、テストの成功を示します。Bazel とテストの間の正確なコントラクト（テスト環境変数、テスト結果収集方法など）は、テスト百科事典で指定されています。
ツールチェーン
言語の出力を構築するための一連のツール。通常、ツールチェーンにはコンパイラ、リンカー、インタープリタ、リンターが含まれます。ツールチェーンはプラットフォームによっても異なる場合があります。つまり、ツールチェーンが同じ言語のものであっても、Unix コンパイラ ツールチェーンのコンポーネントは Windows バリアントで異なる場合があります。プラットフォームに適したツールチェーンを選択することを、ツールチェーン解決と呼びます。
最上位のターゲット
ビルド ターゲットは、Bazel コマンドラインでリクエストされた場合、最上位になります。たとえば、//:foo が //:bar に依存していて、bazel build //:foo が呼び出されると、このビルドでは //:foo が最上位になり、//:bar は最上位になりませんが、両方のターゲットをビルドする必要があります。最上位ターゲットと最上位以外のターゲットの重要な違いは、Bazel コマンドライン（または .bazelrc）で設定されたコマンドフラグは最上位ターゲットの構成を設定しますが、最上位以外のターゲットのトランジションによって変更される可能性があることです。
移行
構成の状態をある値から別の値にマッピングします。同じルールからインスタンス化された場合でも、ビルドグラフ内のターゲットで異なる構成を使用できるようにします。トランジションの一般的な使用法は、分割トランジションです。このトランジションでは、ターゲット グラフの特定の部分がフォークされ、各フォークに個別の構成が設定されます。たとえば、1 回のビルドで分割変換を使用して、ARM と x86 向けにコンパイルされたネイティブ バイナリを含む Android APK をビルドできます。
参照項目: ユーザー定義の遷移
ツリー アーティファクト
ファイルのコレクションを表すアーティファクト。これらのファイルはアーティファクト自体ではないため、これらのファイルを操作するアクションは、代わりにツリー アーティファクトを入力または出力として登録する必要があります。
公開設定
ビルドシステムで不要な依存関係を防ぐための 2 つのメカニズムのうちの 1 つ。ターゲットの可視性は、他のターゲットがターゲットに依存できるかどうかを制御します。読み込みの可視性は、BUILD ファイルまたは .bzl ファイルが特定の .bzl ファイルを読み込めるかどうかを制御します。通常、コンテキストがない場合、「可視性」はターゲットの可視性を指します。
関連情報: 公開設定に関するドキュメント
ワークスペース
ビルドするソフトウェアの WORKSPACE ファイルとソースコードを含むディレクトリ。// で始まるラベルは、ワークスペース ディレクトリを基準にしています。
WORKSPACE ファイル
ディレクトリをワークスペースとして定義します。通常、このファイルにはネットワークまたはローカル ファイル システムから追加の依存関係を取得するための外部リポジトリ宣言が含まれますが、空にすることもできます。