アクション
ビルド中に実行するコマンド（アーティファクトを入力として受け取り、他のアーティファクトを出力として生成するコンパイラの呼び出しなど）。コマンドライン引数、アクションキー、環境変数、宣言された入出力アーティファクトなどのメタデータが含まれます。
関連情報: ルールに関するドキュメント
アクション キャッシュ
実行されたアクションと、そのアクションが作成した出力とのマッピングを保存するディスク上のキャッシュ。キャッシュキーはアクションキーと呼ばれます。Bazel の増分モデルのコア コンポーネント。キャッシュは出力ベース ディレクトリに保存されるため、Bazel サーバーが再起動しても保持されます。
アクション グラフ
アクションと、これらのアクションが読み取って生成するアーティファクトのメモリ内グラフ。グラフには、ソースファイルとして存在するアーティファクト（ファイル システム内など）や、BUILD ファイルに記載されていない生成された中間アーティファクトや最終アーティファクトが含まれる場合があります。分析フェーズで生成され、実行フェーズで使用されます。
アクション グラフのクエリ（aquery）
ビルドのアクションに対してクエリを実行できるクエリ ツール。これにより、ビルドルールが実際の作業ビルドにどのように変換されるかを分析できます。
アクションキー
アクションのキャッシュキー。アクション メタデータに基づいて計算されます。アクション メタデータには、アクションに応じて実行されるコマンド、コンパイラ フラグ、ライブラリの場所、システム ヘッダーなどが含まれる場合があります。Bazel が個々のアクションを確定的にキャッシュまたは無効にできるようにします。
分析フェーズ
ビルドの第 2 フェーズ。BUILD ファイルで指定されたターゲット グラフを処理して、実行フェーズ中に実行するアクションの順序を決定するインメモリ アクション グラフを生成します。このフェーズでは、ルールの実装が評価されます。
アーティファクト
ソースファイルまたは生成ファイル。ファイルのディレクトリ（ツリー アーティファクト）にすることもできます。
アーティファクトは複数のアクションの入力として使用できますが、生成できるのは 1 つのアクションのみです。
ファイル ターゲットに対応するアーティファクトは、ラベルでアドレス指定できます。
Aspect
ルールがその依存関係に追加のアクションを作成するメカニズム。たとえば、ターゲット A が B に依存している場合、A に ASPECT を適用して、B への依存関係エッジを上へ移動し、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 ファイルが含まれていないディレクトリとサブディレクトリをパッケージとしてマークします。また、ルールによって作成されたターゲットを含めることができます。ファイル名は 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 つの異なるアーキテクチャ用にビルドする場合、<//:foo, x86> と <//:foo, arm> の 2 つのターゲットが構成されます。
正確性
ビルドが正しい場合、その出力は伝播入力の状態を忠実に反映しています。Bazel では、正しいビルドを実現するために、密閉型で再現性を確保し、ビルド分析とアクションの実行を確定的にするよう努めています。
依存関係
2 つのターゲット間の有向エッジ。//:foo の属性値に //:bar への参照が含まれている場合、ターゲット //:foo はターゲット //:bar に対するターゲット依存関係を持ちます。//:foo のアクションが //:bar のアクションによって作成された入力アーティファクトに依存している場合、//:foo は //:bar に対するアクションの依存関係を持ちます。
特定のコンテキストでは、外部依存関係を指すこともあります。モジュールをご覧ください。
Depset
推移的依存関係に関するデータを収集するためのデータ構造。非常に大きな depset（数十万のファイル）が一般的に存在するため、depset のマージが時間とスペースを効率的に処理するように最適化されています。スペース効率上の理由から、他の Depset を再帰的に参照するように実装されています。ルールの実装では、ルールがビルドグラフの最上位に配置されていない限り、デプセットをリストに変換して「フラット化」しないでください。大規模なデプセットをフラット化すると、大量のメモリ消費が発生します。Bazel の内部実装では、ネストされたセットとも呼ばれます。
関連情報: Depset のドキュメント
ディスク キャッシュ
リモート キャッシュ機能のためのローカルのディスク上の blob ストア。実際のリモート blob ストアと組み合わせて使用できます。
Distdir
Bazel がリポジトリ ルールを使用してインターネットからフェッチするファイル（読み取り専用ディレクトリ）。ビルドを完全にオフラインで実行できるようにします。
動的実行
さまざまなヒューリスティックに基づいてローカル実行とリモート実行のいずれかを選択し、より高速に成功したメソッドの実行結果を使用する実行方法。特定のアクションはローカルで高速に実行され（リンクなど）、他のアクションはリモートで高速に実行されます（高度な並列化可能なコンパイルなど）。動的実行戦略により、最適な増分かつクリーンなビルド時間を実現できます。
実施フェーズ
ビルドの第 3 フェーズ。分析フェーズで作成されたアクション グラフでアクションを実行します。これらのアクションは、実行可能ファイル（コンパイラ、スクリプト）を呼び出して、アーティファクトの読み取りと書き込みを行います。スポーン戦略は、これらのアクションの実行方法（ローカル、リモート、動的、サンドボックス、Docker など）を制御します。
実行ルート
ワークスペースの出力ベース ディレクトリ内のディレクトリ。サンドボックス化されていないビルドでローカル アクションが実行されます。ディレクトリの内容のほとんどは、ワークスペースからの入力アーティファクトのシンボリック リンクです。実行ルートには、他の入力として外部リポジトリへのシンボリック リンクと、出力を保存する bazel-out ディレクトリも含まれています。ビルドが依存するパッケージの推移閉包を表すディレクトリのシンボリック リンク フォレストを作成することで、読み込みフェーズで準備されます。コマンドラインで bazel info
execution_root を使用してアクセスできます。
ファイル
アーティファクトをご覧ください。
気密性
ビルドとテストのオペレーションに外部からの影響がない場合、ビルドは密閉型であるため、結果が確定的で正しいものになります。たとえば、通常、完全なビルドでは、アクションへのネットワーク アクセスを禁止し、宣言された入力へのアクセスを制限し、固定のタイムスタンプとタイムゾーンを使用し、環境変数へのアクセスを制限し、乱数生成機に固定シードを使用します。
増分ビルド
増分ビルドは、以前のビルドの結果を再利用して、ビルド時間とリソース使用量を削減します。依存関係のチェックとキャッシュ保存の目的は、このタイプのビルドに対して正しい結果を生成することです。増分ビルドはクリーンビルドの反対です。
ラベル
ターゲットの識別子。通常、形式は @repo//path/to/package:target です。ここで、repo はターゲットを含むリポジトリの（明らかな）名前、path/to/package はターゲットを宣言している BUILD ファイルを含むディレクトリ（このディレクトリはパッケージとも呼ばれます）、target はターゲット自体の名前です。状況に応じて、この構文の一部を省略できます。
関連情報: ラベル
読み込みフェーズ
ビルドの最初のフェーズ。Bazel が BUILD ファイルを実行してパッケージを作成します。このフェーズでは、マクロや glob() などの特定の関数が評価されます。ビルドの 2 番目のフェーズである分析フェーズにインターリーブされ、ターゲット グラフを構築します。
マクロ
複数のルール ターゲット宣言を 1 つの Starlark 関数の下に構成するメカニズムです。BUILD ファイル間で一般的なルール宣言パターンを再利用できるようにします。読み込みフェーズ中に、基盤となるルール ターゲット宣言に拡張されます。
関連情報: マクロのドキュメント
ニーモニック
ルールのアクションの動作内容をすばやく把握するために、ルールの作成者が選択する、人が読める短い文字列。メモニクスは、スポーン戦略の選択の識別子として使用できます。アクションの頭文字の例としては、Java ルールの Javac、C++ ルールの CppCompile、Android ルールの AndroidManifestMerger などがあります。
モジュール
複数のバージョンを持つことができる Bazel プロジェクト。各バージョンは他のモジュールに依存できます。これは、Maven アーティファクト、npm パッケージ、Go モジュール、Cargo クレートなど、他の依存関係管理システムにおける一般的なコンセプトに似ています。モジュールは、Bazel の外部依存関係管理システムのバックボーンを形成します。
各モジュールは、ルートに MODULE.bazel ファイルを持つリポジトリを基盤としています。このファイルには、モジュール自体に関するメタデータ（名前やバージョンなど）、直接的な依存関係、その他のさまざまなデータ（ツールチェーンの登録やモジュール拡張入力など）が含まれています。
モジュール メタデータは Bazel レジストリでホストされます。
関連情報: Bazel モジュール
モジュール拡張機能
モジュール依存関係グラフ全体から入力を読み取り、リポジトリ ルールを呼び出すことによって repos を生成するために実行できるロジック。モジュール拡張機能には、リポジトリ ルールに似た機能があり、インターネットへのアクセスやファイル I/O の実行などが可能です。
関連情報: モジュールの拡張機能
ネイティブ ルール
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 が実行されるマシン（「ホスト」プラットフォーム）、ビルドツールが実行されるマシン（「exec」プラットフォーム）、ビルド対象のマシン（「ターゲット プラットフォーム」）が含まれます。
プロバイダ
依存関係に沿ってルール ターゲット間で渡す情報の単位を記述するスキーマ。通常、このファイルには、コンパイラ オプション、推移的なソースファイルや出力ファイル、ビルド メタデータなどの情報が含まれます。多くの場合、depsets と組み合わせて使用され、累積された伝播データを効率的に保存します。組み込みプロバイダの例は DefaultInfo です。
関連情報: プロバイダのドキュメント
クエリ（コンセプト）
ビルドグラフを分析して、ターゲットのプロパティと依存関係の構造を理解するプロセス。Bazel では、query、cquery、aquery の 3 つのクエリ バリアントがサポートされています。
query（コマンド）
ビルドの読み込みフェーズ後のターゲット グラフに対して動作するクエリ ツール。これは比較的高速ですが、select()、ビルドフラグ、アーティファクト、ビルドアクションの効果を分析することはできません。
関連情報: クエリの方法、クエリのリファレンス
リポジトリ
ルートに境界マーカー ファイルがあり、Bazel ビルドで使用できるソースファイルを含むディレクトリ ツリー。多くの場合、リポのために短縮されます。
リポジトリ境界マーカー ファイルは、MODULE.bazel（このリポジトリが Bazel モジュールを表すことを示します）、REPO.bazel、または以前のコンテキストでは WORKSPACE または WORKSPACE.bazel にできます。リポジトリ境界マーカー ファイルは、リポジトリの境界を表します。このようなファイルはディレクトリ内に複数存在できます。
メイン リポジトリは、現在の Bazel コマンドが実行されているリポジトリです。
外部リポジトリを定義するには、MODULE.bazel ファイルでモジュールを指定するか、モジュール拡張機能でリポルールを呼び出します。これらのファイルは、ディスク上の事前定義された「魔法の」場所にオンデマンドでフェッチできます。
各リポジトリには一意で一定の正規名があり、他のリポジトリから見たときに見分け名前が異なる可能性があります。
関連情報: 外部依存関係の概要
リポジトリ キャッシュ
Bazel がビルド用にダウンロードしたファイルの共有コンテンツ アドレス指定キャッシュ。ワークスペース間で共有できます。初回ダウンロード後のオフライン ビルドを有効にします。通常、http_archive などのリポジトリ ルールや repository_ctx.download などのリポジトリ ルール API を介してダウンロードされたファイルをキャッシュに保存するために使用されます。ファイルは、ダウンロードに SHA-256 チェックサムが指定されている場合にのみキャッシュに保存されます。
リポジトリ ルール
リポジトリをマテリアライズ（または「フェッチ」）する方法を指定するリポジトリ定義のスキーマ。多くの場合、repo rule と略されます。リポジトリ ルールは、モジュールが基盤となるリポジトリを定義するために Bazel によって内部的に呼び出されます。また、モジュール拡張機能によって呼び出すこともでき、Repo ルールは、インターネットへのアクセスやファイル I/O を実行できます。最も一般的なリポジトリ ルールは、インターネットからソースファイルを含むアーカイブをダウンロードする http_archive です。
関連情報: Repo ルールのドキュメント
再現性
ビルドまたはテストへの入力セットが、時間、方法、環境に関係なく、常に同じ出力セットを生成するビルドまたはテストのプロパティ。これは、必ずしも出力が正しい出力または目的の出力であることを意味するわけではありません。
ルール
BUILD ファイルでルール ターゲットを定義するためのスキーマ（cc_library など）。BUILD ファイルの作成者の観点から、ルールは属性とブラックボックス ロジックのセットで構成されています。このロジックは、出力アーティファクトを生成し、他のルール ターゲットに情報を渡す方法をルール ターゲットに指示します。.bzl の作成者から見ると、ルールが Bazel を拡張して新しいプログラミング言語と環境をサポートする主要な方法です。
ルールは、読み込みフェーズでインスタンス化され、ルール ターゲットを生成します。分析フェーズでは、ルール ターゲットがプロバイダの形式でダウンストリームの依存関係に情報を伝達し、出力アーティファクトの生成方法を記述するアクションを登録します。これらのアクションは、実行フェーズで実行されます。
関連情報: ルールのドキュメント
ルールのターゲット
ルールのインスタンスであるターゲット。ファイルターゲットや パッケージグループとは対照的ですルールと混同しないでください。
実行ファイル
実行可能なターゲットのランタイム依存関係。通常、実行ファイルはテストルールの実行可能出力であり、ランファイルはテストのランタイム データ依存関係です。実行可能ファイルが呼び出される前に（bazel テスト中）、Bazel はソース ディレクトリ構造に従って、テスト実行可能ファイルとともに runfile のツリーを準備します。
関連情報: Runfiles ドキュメント
サンドボックス化
実行中のアクションを、制限付きの一時的な実行ルート内で分離する手法。宣言されていない入力の読み取りや、宣言されていない出力の書き込みを防止できます。サンドボックス化は完全性を大幅に向上させますが、通常はパフォーマンスのコストがかかり、オペレーティング システムからのサポートが必要です。パフォーマンス コストはプラットフォームによって異なります。Linux では問題ありませんが、macOS ではサンドボックスを使用できなくなる可能性があります。
Skyframe
Skyframe は、Bazel のコア並列、関数、増分評価フレームワークです。
スタンピング
Bazel でビルドされたアーティファクトに追加情報を埋め込む機能。たとえば、リリースビルドのソース管理、ビルド時間、その他のワークスペースまたは環境関連情報に使用できます。--workspace_status_command フラグとスタンプ属性をサポートするルールを使用して有効にします。
スターラーク
ルールとマクロを記述するための拡張言語。構成とパフォーマンスの向上を目的とする Python の制限されたサブセット（構文的および文法的に）。.bzl ファイル拡張子を使用します。BUILD ファイルは、Starlark のさらに制限付きバージョン（def 関数の定義なしなど）を使用します（旧称 Skylark）。
関連情報: Starlark 言語のドキュメント
起動フラグ
bazel とコマンドの間に指定されたフラグのセット（bazel --host_jvm_debug build など）。これらのフラグは 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 ファイルを読み込めるかどうかを制御する読み込みの可視性。コンテキストがなければ、通常、「可視性」はターゲットの可視性を指します。
関連情報: 公開設定に関するドキュメント
ワークスペース
すべての Bazel コマンドで共有される環境は、同じメイン リポジトリから実行されます。
これまで、「リポジトリ」と「ワークスペース」のコンセプトは混同されてきました。「ワークスペース」という用語はメイン リポジトリを指すために使用され、場合によっては「リポジトリ」の同義語として使用されることさえあります。明確にするために、このような使用は避けてください。