アクション
ビルド中に実行するコマンド（アーティファクトを入力として受け取り、他のアーティファクトを出力として生成するコンパイラの呼び出しなど）。コマンドライン引数、アクションキー、環境変数、宣言された入出力アーティファクトなどのメタデータが含まれます。
関連情報: ルールに関するドキュメント
アクション キャッシュ
実行されたアクションと、そのアクションが作成した出力とのマッピングを保存するディスク上のキャッシュ。キャッシュキーはアクションキーと呼ばれます。Bazel のインクリメンタリティ モデルのコア コンポーネント。キャッシュは出力ベース ディレクトリに保存されるため、Bazel サーバーが再起動しても保持されます。
アクション グラフ
アクションと、これらのアクションが読み取って生成するアーティファクトのメモリ内グラフ。グラフには、ソースファイル（ファイル システム内など）として存在するアーティファクトや、BUILD ファイルに記述されていない生成された中間/最終アーティファクトが含まれる場合があります。分析フェーズで生成され、実行フェーズで使用されます。
アクション グラフのクエリ（aquery）
ビルド アクションに対してクエリを実行できるクエリツール。これにより、ビルドルールが実際の作業ビルドにどのように変換されるかを分析できるようになります。
アクションキー
アクションのキャッシュキー。アクション メタデータに基づいて計算されます。アクション メタデータには、アクションに応じて実行されるコマンド、コンパイラ フラグ、ライブラリの場所、システム ヘッダーなどが含まれる場合があります。Bazel によるキャッシュへの保存や、個々のアクションの決定的な無効化を有効にします。
分析フェーズ
ビルドの 2 番目のフェーズ。BUILD ファイルで指定されたターゲット グラフを処理して、実行フェーズで実行するアクションの順序を決定するメモリ内アクション グラフを生成します。このフェーズでは、ルールの実装が評価されます。
アーティファクト
ソースファイルまたは生成されたファイル。ファイルのディレクトリ（ツリー アーティファクト）にすることもできます。
アーティファクトは複数のアクションへの入力になり得ますが、生成できるアクションは 1 つだけです。
ファイル ターゲットに対応するアーティファクトは、ラベルでアドレス指定できます。
アスペクト
ルールがその依存関係に追加のアクションを作成するメカニズム。たとえば、ターゲット A が B に依存している場合、依存関係エッジを上って B に移動する A にアスペクトを適用し、B で追加のアクションを実行して、追加の出力ファイルを生成して収集できます。これらの追加のアクションは、キャッシュに保存され、同じアスペクトを必要とするターゲット間で再利用されます。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 ファイルを含まないディレクトリとサブディレクトリをパッケージとしてマークし、rules によって作成されたターゲットを含めることができます。ファイル名は BUILD.bazel にすることもできます。
BUILD.bazel ファイル
BUILD ファイルをご覧ください。同じディレクトリ内の BUILD ファイルよりも優先されます。
.bzl ファイル
Starlark で記述されたルール、マクロ、定数を定義するファイル。これらは、load() 関数を使用して BUILD ファイルにインポートできます。
グラフを作成する
ビルドを実行するために Bazel が作成して走査する依存関係グラフ。ターゲット、構成されたターゲット、アクション、アーティファクトなどのノードが含まれます。リクエストされた一連のターゲットが依存するすべてのアーティファクトが最新であることが確認されると、ビルドは完了とみなされます。
ビルド設定
Starlark が定義する構成。遷移では、ビルド設定を指定してサブグラフの構成を変更できます。コマンドライン フラグ（ビルドフラグ）としてユーザーに公開されている場合。
クリーンビルド
以前のビルドの結果を使用しないビルド。通常、増分ビルドよりも時間がかかりますが、より正確とみなされます。Bazel は、クリーンビルドと増分ビルドの両方が常に正確であることを保証します。
クライアント サーバー モデル
bazel コマンドライン クライアントは、ローカルマシンでバックグラウンド サーバーを自動的に起動し、Bazel コマンドを実行します。サーバーはコマンドをまたいで持続しますが、非アクティブな状態が一定時間続くと（または bazel シャットダウンによって明示的に）自動的に停止します。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 をビルドする場合、--javacopt を不必要に変更すると C++ ビルドのキャッシュ可能性が損なわれるため、//:c の構成に --javacopt の値を含めるのは無駄になります。
設定済みのクエリ（cquery）
構成されたターゲットに対してクエリを実行するクエリツール（分析フェーズの完了後）。つまり、select() とビルドフラグ（--platforms など）が結果に正確に反映されています。
関連情報: cquery のドキュメント
構成済みのターゲット
構成を使用したターゲットの評価結果。分析フェーズでは、ビルドのオプションとビルドする必要があるターゲットを組み合わせて、これを作成します。たとえば、//:foo が同じビルド内の 2 つの異なるアーキテクチャ用にビルドする場合、2 つのターゲット（<//:foo, x86> と <//:foo, arm>）が構成されます。
正確性
出力が推移的入力の状態を忠実に反映している場合、ビルドは正確です。Bazel では、正しいビルドを実現するために、密閉型で再現性を確保し、ビルド分析とアクションの実行を確定的にするよう努めています。
依存関係
2 つのターゲット間の有向エッジ。//:foo の属性値に //:bar への参照が含まれている場合、ターゲット //:foo はターゲット //:bar に対するターゲット依存関係を持ちます。//:foo のアクションが //:bar のアクションによって作成された入力アーティファクトに依存している場合、//:foo は //:bar に対するアクションの依存関係を持ちます。
出発
推移的依存関係に関するデータを収集するためのデータ構造。非常に大規模な depset（数十万のファイル）が一般的に存在するため、depset のマージが時間とスペースを効率的に処理するように最適化されています。スペース効率の理由から他の依存関係を再帰的に参照するように実装されています。ルールの実装では、ルールがビルドグラフの最上位に配置されていない限り、デプセットをリストに変換して「フラット化」しないでください。大きな depset をフラット化すると、大量のメモリ消費が発生します。Bazel の内部実装では、ネストされたセットとも呼ばれます。
関連情報: Depset のドキュメント
ディスク キャッシュ
リモート キャッシュ機能のためのローカルのディスク上の blob ストア。実際のリモート blob ストアと組み合わせて使用できます。
ディストリビューター
Bazel がリポジトリ ルールを使用してインターネットからフェッチするファイル（読み取り専用ディレクトリ）。ビルドを完全にオフラインで実行できます。
動的実行
さまざまなヒューリスティックに基づいてローカル実行とリモート実行のいずれかを選択し、より高速に成功したメソッドの実行結果を使用する実行方法。アクションには、ローカルで高速に実行されるもの（リンクなど）と、リモートで高速に実行されるアクション（並列化可能なコンパイルなど）があります。動的実行戦略により、最適な増分かつクリーンなビルド時間を実現できます。
実施フェーズ
ビルドの 3 番目のフェーズ。分析フェーズで作成したアクション グラフのアクションを実行します。これらのアクションは、実行可能ファイル（コンパイラ、スクリプト）を呼び出して、アーティファクトの読み取りと書き込みを行います。生成戦略は、これらのアクションの実行方法（ローカル、リモート、動的、サンドボックス化、Docker など）を制御します。
実行ルート
ワークスペースの出力ベース ディレクトリ内のディレクトリ。サンドボックス化されていないビルドでローカル アクションが実行されます。ディレクトリの内容のほとんどは、ワークスペースからの入力アーティファクトのシンボリック リンクです。実行ルートには、他の入力としての外部リポジトリと、出力を保存する bazel-out ディレクトリへのシンボリック リンクも含まれています。読み込みフェーズで準備するために、ビルドが依存するパッケージの推移的クロージャを表すディレクトリのシンボリック リンク フォレストを作成します。コマンドラインで bazel info
execution_root を使用してアクセスできます。
File
アーティファクトをご覧ください。
密閉性
ビルドとテストのオペレーションに外部からの影響がない場合、ビルドは密閉型であるため、結果が確定的で正しいものになります。たとえば、密閉型のビルドでは通常、アクションへのネットワーク アクセスを禁止し、宣言された入力へのアクセスを制限し、固定のタイムスタンプとタイムゾーンを使用し、環境変数へのアクセスを制限し、乱数ジェネレータに固定シードを使用します。
増分ビルド
増分ビルドでは、以前のビルドの結果を再利用して、ビルド時間とリソース使用量を削減します。依存関係のチェックとキャッシュ保存の目的は、このタイプのビルドに対して正しい結果を生成することです。増分ビルドはクリーンビルドの逆です。
ラベル
ターゲットの識別子。//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 で実装されているルール。このようなルールは、ネイティブ モジュール（native.cc_library や native.java_library など）の関数として .bzl ファイルに記述されます。ユーザー定義のルール（非ネイティブ）は Starlark を使用して作成されます。
出力ベース
Bazel 出力ファイルを保存するためのワークスペース固有のディレクトリ。ワークスペースのソースツリーから出力を分離するために使用します。出力ユーザーのルートにあります。
出力グループ
Bazel がターゲットのビルドを終了したときにビルドされると予想されるファイルのグループ。ルールでは、通常の出力が「デフォルトの出力グループ」に配置されます（たとえば、cc_library ターゲットの java_library、.a、.so の .jar ファイル）。デフォルトの出力グループは、コマンドラインでターゲットがリクエストされたときにアーティファクトがビルドされる出力グループです。ルールでは、より多くの名前付き出力グループを定義できます。これは、BUILD ファイル（filegroup ルール）またはコマンドライン（--output_groups フラグ）で明示的に指定できます。
出力ユーザールート
Bazel の出力を保存するユーザー固有のディレクトリ。ディレクトリ名は、ユーザーのシステム ユーザー名から取得されます。複数のユーザーがシステムで同じプロジェクトを同時にビルドする場合に、出力ファイルの競合を回避します。個々のワークスペースのビルド出力に対応するサブディレクトリ（出力ベース）が含まれています。
パッケージ
BUILD ファイルで定義されたターゲットのセット。パッケージの名前は、ワークスペースのルートを基準とする BUILD ファイルの相対パスです。パッケージには、サブパッケージまたは BUILD ファイルを含むサブディレクトリを含めることができるため、パッケージ階層を形成できます。
パッケージ グループ
一連のパッケージを表すターゲット。多くの場合、visibility 属性値で使用されます。
プラットフォーム
ビルドに関与する「マシンタイプ」。これには、Bazel が実行されるマシン（「ホスト」プラットフォーム）、ビルドツールが実行されるマシン（「exec」プラットフォーム）、ビルド対象のマシン（「ターゲット プラットフォーム」）が含まれます。
プロバイダ
依存関係の関係に沿ってルール ターゲット間で受け渡しする情報の単位を記述するスキーマ。通常、このファイルには、コンパイラ オプション、推移的なソースファイルまたは出力ファイル、ビルド メタデータなどの情報が含まれます。蓄積された推移データを効率的に保存するために、depset と組み合わせて頻繁に使用されます。組み込みプロバイダの例として、DefaultInfo があります。
関連情報: プロバイダのドキュメント
クエリ（コンセプト）
ビルドグラフを分析して、ターゲットのプロパティと依存関係の構造を理解するプロセス。Bazel では、query、cquery、aquery の 3 つのクエリ バリアントがサポートされています。
query（コマンド）
ビルドの読み込み後フェーズのターゲット グラフで動作するクエリツール。これは比較的高速ですが、select()、ビルドフラグ、アーティファクト、ビルド アクションの影響を分析することはできません。
関連情報: クエリの使用方法、クエリ リファレンス
リポジトリ キャッシュ
ビルドのために Bazel によってダウンロードされたファイルのコンテンツ アドレス指定可能な共有キャッシュ。ワークスペース間で共有できます。初回ダウンロード後のオフライン ビルドを有効にします。http_archive などのリポジトリ ルールや repository_ctx.download などのリポジトリ ルール API を介してダウンロードしたファイルをキャッシュに保存するためによく使用されます。ダウンロードに SHA-256 チェックサムが指定されている場合にのみ、ファイルがキャッシュに保存されます。
再現性
時間、メソッド、環境に関係なく、ビルドまたはテストへの入力セットが毎回同じ出力セットを生成するという、ビルドまたはテストのプロパティ。これは、必ずしも出力が正しい出力または目的の出力であることを意味するわけではありません。
ルール
BUILD ファイルでルール ターゲットを定義するためのスキーマ（cc_library など）。BUILD ファイルの作成者から見ると、ルールは属性とブラック ボックス ロジックのセットで構成されます。このロジックは、出力アーティファクトを生成し、他のルール ターゲットに情報を渡す方法をルール ターゲットに指示します。.bzl の作成者から見ると、ルールが Bazel を拡張して新しいプログラミング言語と環境をサポートする主要な方法です。
ルールは、読み込みフェーズでルール ターゲットを生成するためにインスタンス化されます。分析フェーズでは、ルール ターゲットはプロバイダの形式でダウンストリームの依存関係に情報を伝達し、出力アーティファクトの生成方法を記述するアクションを登録します。これらのアクションは、実行フェーズで実行されます。
関連情報: ルールに関するドキュメント
ルールのターゲット
ルールのインスタンスであるターゲット。ファイルターゲットや パッケージグループとは対照的ですルールと混同しないでください。
実行ファイル
実行可能なターゲットのランタイム依存関係。ほとんどの場合、実行可能ファイルはテストルールの実行可能な出力であり、実行ファイルはテストのランタイム データの依存関係です。実行可能ファイルが呼び出される前に（bazel テスト中）、Bazel はソース ディレクトリ構造に従って、テスト実行可能ファイルとともに runfile のツリーを準備します。
関連情報: Runfiles ドキュメント
サンドボックス化
実行中のアクションを、制限付きの一時的な実行ルート内で分離する手法。宣言されていない入力の読み取りや、宣言されていない出力の書き込みを防止できます。サンドボックス化すると密閉性が大幅に向上しますが、通常はパフォーマンス コストがかかり、オペレーティング システムのサポートが必要です。パフォーマンス コストはプラットフォームによって異なります。Linux では重要ではありませんが、macOS ではサンドボックスが使用できなくなる可能性があります。
スカイフレーム
Skyframe は、Bazel の中核となる並列性、機能性、増分評価フレームワークです。
スタンピング
Bazel でビルドされたアーティファクトに追加の情報を埋め込む機能。たとえば、リリースビルドのソース管理、ビルド時間、その他のワークスペースや環境関連の情報に使用できます。stamp 属性をサポートする --workspace_status_command フラグとルールを使用して有効にします。
スターラーク
ルールとマクロを作成するための拡張言語。構成とパフォーマンスの向上を目的とする Python の制限されたサブセット（構文的および文法的に）。.bzl ファイル拡張子を使用します。BUILD ファイルは、Starlark のさらに制限付きバージョン（def 関数の定義なしなど）を使用します（旧称 Skylark）。
関連情報: Starlark 言語のドキュメント
起動フラグ
bazel とコマンドの間で指定されたフラグのセット（例: bazel --host_jvm_debug ビルド）。これらのフラグは Bazel サーバーの構成を変更するため、起動フラグを変更するとサーバーが再起動されます。起動フラグは特定のコマンドに固有のものではありません。
ターゲット
BUILD ファイルで定義され、ラベルで識別されるオブジェクト。ターゲットは、エンドユーザーの観点から見たワークスペースのビルド可能なユニットを表します。
ルールをインスタンス化して宣言されたターゲットは、ルール ターゲットと呼ばれます。ルールに応じて、これらは実行可能（cc_binary など）またはテスト可能（cc_test など）になります。ルールのターゲットは通常、属性（deps など）を介して他のターゲットに依存します。これらの依存関係はターゲット グラフの基礎を形成します。
ルール ターゲット以外にも、ファイル ターゲットとパッケージ グループ ターゲットがあります。ファイル ターゲットは、BUILD ファイル内で参照されるアーティファクトに対応します。特別なケースとして、パッケージの BUILD ファイルは常に、そのパッケージ内のソースファイルのターゲットとみなされます。
ターゲットは、読み込みフェーズで検出されます。分析フェーズで、ターゲットはビルド構成に関連付けられ、構成済みのターゲットを形成します。
ターゲットのグラフ
ターゲットとその依存関係のメモリ内グラフ。読み込みフェーズで生成され、分析フェーズの入力として使用されます。
ターゲット パターン
コマンドラインでターゲットのグループを指定する方法。よく使用されるパターンは、:all（すべてのルール ターゲット）、:*（すべてのルールとファイル ターゲット）、...（現在のパッケージとすべてのサブパッケージを再帰的に）です。組み合わせて使用できます。たとえば、//...:* は、ワークスペースのルートから再帰的にすべてのパッケージ内のすべてのルールとファイル ターゲットを意味します。
テスト
ルールはテストルールからインスタンス化されたターゲットであるため、テスト実行可能ファイルを含みます。実行可能ファイルの完了からの戻りコード 0 は、テストが成功したことを示します。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 ファイル
ディレクトリをワークスペースとして定義します。このファイルは空にすることもできますが、通常はネットワークまたはローカル ファイル システムから追加の依存関係を取得するための外部リポジトリ宣言が含まれています。