アクション
ビルド中に実行するコマンド。たとえば、アーティファクトを入力として受け取り、他のアーティファクトを出力として生成するコンパイラを呼び出すコマンドなどです。コマンドライン引数、アクションキー、環境変数、宣言された入出力アーティファクトなどのメタデータが含まれます。
関連情報: ルールのドキュメント
アクション キャッシュ
実行されたアクションと作成された出力のマッピングを保存するオンディスク キャッシュ。キャッシュキーはアクションキーと呼ばれます。Bazel の増分モデルのコア コンポーネント。キャッシュは出力ベース ディレクトリに保存されるため、Bazel サーバーの再起動後も保持されます。
アクショングラフ
アクションと、これらのアクションが読み取り生成するアーティファクトのメモリ内グラフ。グラフには、ソースファイルとして存在するアーティファクト（ファイル システム内など）や、BUILD ファイルに記載されていない生成された中間アーティファクトや最終アーティファクトが含まれる場合があります。分析フェーズで生成され、実行フェーズで使用されます。
アクショングラフ クエリ（aquery）
ビルドアクションに対してクエリを実行できるクエリ ツール。これにより、ビルドルールが実際の作業ビルドにどのように変換されるかを分析できます。
アクションキー
アクションのキャッシュキー。アクションのメタデータに基づいて計算されます。アクションに応じて、アクションで実行されるコマンド、コンパイラ フラグ、ライブラリの場所、システム ヘッダーなどが含まれます。Bazel が個々のアクションを確定的にキャッシュまたは無効にできるようにします。
分析フェーズ
ビルドの第 2 フェーズ。BUILD ファイルで指定されたターゲット グラフを処理して、実行フェーズ中に実行するアクションの順序を決定するインメモリ アクション グラフを生成します。これは、ルールの実装が評価されるフェーズです。
アーティファクト
ソースファイルまたは生成ファイル。ファイルのディレクトリ（ツリー アーティファクト）にすることもできます。
アーティファクトは複数のアクションの入力として使用できますが、生成できるのは 1 つのアクションのみです。
ファイル ターゲットに対応するアーティファクトには、ラベルでアクセスできます。
Aspect
依存関係に追加のアクションを作成するルールのメカニズム。たとえば、ターゲット A が B に依存している場合、A に ASPECT を適用して、B への依存関係エッジを上へ移動し、B で追加のアクションを実行して、追加の出力ファイルを生成して収集できます。これらの追加アクションはキャッシュに保存され、同じアスペクトを必要とするターゲット間で再利用されます。aspect() Starlark Build API 関数で作成されます。たとえば、IDE のメタデータを生成したり、リンティング用のアクションを作成したりできます。
関連情報: アスペクトのドキュメント
アスペクト オン アスペクト
アスペクトを他のアスペクトの結果に適用できるコンポジション メカニズム。たとえば、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 の構成に含めるのは無駄です。--javacopt を変更すると、C++ ビルドのキャッシュ保存性が不必要に破棄されるためです。
構成済みクエリ（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 を再帰的に参照するように実装されています。ルールの実装では、ルールがビルドグラフの最上位レベルにある場合を除き、depset をリストに変換して「フラット化」しないでください。大規模な depset をフラット化すると、メモリ使用量が大幅に増加します。Bazel の内部実装ではネストされたセットとも呼ばれます。
関連情報: Depset のドキュメント
ディスク キャッシュ
リモート キャッシュ機能用のローカル オンディスク blob ストア。実際のリモート blob ストアと組み合わせて使用できます。
Distdir
Bazel がリポジトリ ルールを使用してインターネットから取得するファイルを格納する読み取り専用ディレクトリ。ビルドを完全にオフラインで実行できるようにします。
動的実行
さまざまなヒューリスティックに基づいてローカル実行とリモート実行のどちらかを選択し、より速く成功した方法の実行結果を使用する実行戦略。特定のアクションはローカルで高速に実行され（リンクなど）、他のアクションはリモートで高速に実行されます（高度な並列化可能なコンパイルなど）。動的実行戦略では、可能な限り最小限のクリーンな増分ビルド時間を実現できます。
実施フェーズ
ビルドの第 3 フェーズ。分析フェーズで作成されたアクション グラフでアクションを実行します。これらのアクションは、実行可能ファイル（コンパイラ、スクリプト）を呼び出してアーティファクトの読み取りと書き込みを行います。スポーン戦略は、これらのアクションの実行方法（ローカル、リモート、動的、サンドボックス、Docker など）を制御します。
実行ルート
ワークスペースの出力ベース ディレクトリ内のディレクトリ。サンドボックス化されていないビルドでローカル アクションが実行されます。ディレクトリの内容は、ほとんどがワークスペースからの入力アーティファクトのシンボリック リンクです。実行ルートには、他の入力として外部リポジトリへのシンボリック リンクと、出力を保存する bazel-out ディレクトリも含まれています。ビルドが依存するパッケージの推移閉包を表すディレクトリのシンボリック リンク フォレストを作成することで、読み込みフェーズで準備されます。コマンドラインで bazel info
execution_root を使用してアクセスできます。
ファイル
アーティファクトをご覧ください。
Hermeticity
ビルドとテストのオペレーションに外部の影響がない場合、ビルドは気密性があります。これにより、結果が確定的かつ正確であることを確認できます。たとえば、通常、完全なビルドでは、アクションへのネットワーク アクセスを禁止し、宣言された入力へのアクセスを制限し、固定のタイムスタンプとタイムゾーンを使用し、環境変数へのアクセスを制限し、乱数生成機に固定シードを使用します。
増分ビルド
増分ビルドは、以前のビルドの結果を再利用して、ビルド時間とリソース使用量を削減します。依存関係チェックとキャッシュ保存は、このタイプのビルドで正しい結果を生成することを目的としています。増分ビルドはクリーンビルドの反対です。
ラベル
ターゲットの識別子。通常、@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 のcrate など、他の依存関係管理システムのよく知られたコンセプトに似ています。モジュールは、Bazel の外部依存関係管理システムのバックボーンとなります。
各モジュールは、ルートに MODULE.bazel ファイルがあるrepoによってサポートされています。このファイルには、モジュール自体に関するメタデータ（名前やバージョンなど）、直接的な依存関係、その他のさまざまなデータ（ツールチェーンの登録やモジュール拡張の入力など）が含まれています。
モジュール メタデータは Bazel レジストリでホストされます。
関連情報: Bazel モジュール
モジュール拡張機能
モジュール依存関係グラフ全体から入力を読み取り、リポジトリ ルールを呼び出して、reposを生成するために実行できるロジック。モジュール拡張機能には、リポジトリ ルールに似た機能があり、インターネットへのアクセスやファイル I/O の実行などが可能です。
関連項目: モジュール拡張機能
ネイティブ ルール
Bazel に組み込まれ、Java で実装されたルール。このようなルールは、ネイティブ モジュールの関数として .bzl ファイルに表示されます（native.cc_library や native.java_library など）。ユーザー定義ルール（ネイティブ以外）は Starlark を使用して作成されます。
出力ベース
Bazel 出力ファイルを保存するワークスペース固有のディレクトリ。ワークスペースのソースツリー（メイン リポジトリ）から出力を分離するために使用されます。出力ユーザーのルートにあります。
出力グループ
Bazel がターゲットのビルドを完了したときにビルドされることが期待されるファイルのグループ。ルールは、通常の出力を「デフォルトの出力グループ」に配置します（例: java_library の .jar ファイル、cc_library ターゲットの .a と .so）。デフォルト出力グループは、コマンドラインでターゲットがリクエストされたときにアーティファクトがビルドされる出力グループです。ルールでは、BUILD ファイル（filegroup ルール）またはコマンドライン（--output_groups フラグ）で明示的に指定できる名前付き出力グループを定義できます。
ユーザー root を出力する
Bazel の出力を保存するユーザー固有のディレクトリ。ディレクトリ名は、ユーザーのシステム ユーザー名から派生します。複数のユーザーがシステム上で同じプロジェクトを同時にビルドしている場合に、出力ファイルの競合を防ぎます。個々のワークスペースのビルド出力（出力ベース）に対応するサブディレクトリが含まれています。
パッケージ
BUILD ファイルで定義されたターゲットのセット。パッケージの名前は、repoのルートからの BUILD ファイルのパスです。パッケージにはサブパッケージ（BUILD ファイルを含むサブディレクトリ）を含めることができ、パッケージ階層を形成できます。
パッケージ グループ
一連のパッケージを表すターゲット。visibility 属性値でよく使用されます。
プラットフォーム
ビルドに関連する「マシンタイプ」。これには、Bazel が実行されるマシン（「ホスト」プラットフォーム）、ビルドツールが実行されるマシン（「実行」プラットフォーム）、ターゲット マシンがビルドされるマシン（「ターゲット プラットフォーム」）が含まれます。
プロバイダ
依存関係に沿ってルール ターゲット間で渡す情報の単位を記述するスキーマ。通常、コンパイラ オプション、伝播ソースまたは出力ファイル、ビルドメタデータなどの情報が含まれます。多くの場合、depsets と組み合わせて使用され、累積された伝播データを効率的に保存します。組み込みプロバイダの例は DefaultInfo です。
関連情報: プロバイダのドキュメント
クエリ（コンセプト）
ビルドグラフを分析して、ターゲットのプロパティと依存関係の構造を把握するプロセス。Bazel は、query、cquery、aquery の 3 つのクエリ バリエーションをサポートしています。
query（コマンド）
ビルドの読み込みフェーズ後のターゲット グラフに対して動作するクエリ ツール。これは比較的高速ですが、select()、ビルドフラグ、アーティファクト、ビルドアクションの効果を分析することはできません。
関連情報: クエリの方法、クエリのリファレンス
リポジトリ
ルートに境界マーカー ファイルがあり、Bazel ビルドで使用できるソースファイルを含むディレクトリ ツリー。多くの場合、repo と省略されます。
リポジトリ境界マーカー ファイルは、MODULE.bazel（このリポジトリが Bazel モジュールを表すことを通知）、REPO.bazel、またはレガシー コンテキストでは WORKSPACE または WORKSPACE.bazel です。リポジトリ境界マーカー ファイルは、リポジトリの境界を表します。このようなファイルはディレクトリ内に複数存在できます。
メイン リポジトリは、現在の Bazel コマンドが実行されているリポジトリです。
外部リポジトリは、MODULE.bazel ファイルでモジュールを指定する、またはモジュール拡張機能でリポジトリ ルールを呼び出すことで定義されます。これらのファイルは、ディスク上の事前定義された「魔法の」場所にオンデマンドでフェッチできます。
各リポジトリには一意の固定の正規名があり、他のリポジトリから見た見かけの名前が異なる場合があります。
関連情報: 外部依存関係の概要
リポジトリ キャッシュ
Bazel がビルド用にダウンロードしたファイルの共有コンテンツ アドレス指定キャッシュ。ワークスペース間で共有できます。最初のダウンロード後にオフライン ビルドを有効にします。http_archive などのリポジトリ ルールや repository_ctx.download などのリポジトリ ルール API を介してダウンロードされたファイルをキャッシュに保存するためによく使用されます。ファイルは、ダウンロードに SHA-256 チェックサムが指定されている場合にのみキャッシュに保存されます。
リポジトリ ルール
リポジトリをマテリアライズ（または「フェッチ」）する方法を指定するリポジトリ定義のスキーマ。多くの場合、repo rule と略されます。リポジトリ ルールは、モジュールが基盤となるリポジトリを定義するために Bazel によって内部的に呼び出されます。また、モジュール拡張機能によって呼び出すこともできます。リポジトリ ルールはインターネットにアクセスしたり、ファイル I/O を実行したりできます。最も一般的なリポジトリ ルールは、ソースファイルを含むアーカイブをインターネットからダウンロードする http_archive です。
関連情報: リポジトリ ルールのドキュメント
再現性
ビルドまたはテストへの入力セットが、時間、方法、環境に関係なく、常に同じ出力セットを生成するビルドまたはテストのプロパティ。これは、出力が正しい、または目的の出力であるとは限りません。
ルール
BUILD ファイル（cc_library など）でルール ターゲットを定義するためのスキーマ。BUILD ファイルの作成者の観点から、ルールは属性とブラックボックス ロジックのセットで構成されています。このロジックは、出力アーティファクトを生成し、他のルール ターゲットに情報を渡す方法をルール ターゲットに指示します。.bzl の作成者の観点から、ルールは Bazel を拡張して新しいプログラミング言語と環境をサポートするための主な方法です。
ルールは、読み込みフェーズでインスタンス化され、ルール ターゲットを生成します。分析フェーズでは、ルール ターゲットがプロバイダの形式でダウンストリームの依存関係に情報を伝達し、出力アーティファクトの生成方法を記述するアクションを登録します。これらのアクションは、実行フェーズで実行されます。
関連情報: ルールのドキュメント
ルールのターゲット
ルールのインスタンスであるターゲット。ファイル ターゲットやパッケージ グループとは対照的です。ルールとは異なります。
Runfiles
実行可能ターゲットのランタイム依存関係。通常、実行ファイルはテストルールの実行可能出力であり、ランファイルはテストのランタイム データ依存関係です。実行可能ファイルの呼び出しの前に（bazel テスト中）、Bazel はソース ディレクトリ構造に従って、テスト実行可能ファイルとともに実行ファイルのツリーを準備します。
関連情報: Runfile のドキュメント
サンドボックス化
制限付きの一時的な実行ルート内に実行中のアクションを分離する手法。宣言されていない入力を読み取ったり、宣言されていない出力を書き込んだりしないようにします。サンドボックス化は完全性を大幅に向上させますが、通常はパフォーマンスのコストがかかり、オペレーティング システムからのサポートが必要です。パフォーマンス コストはプラットフォームによって異なります。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 バリアントと異なる場合があります。プラットフォームに適した toolchain を選択することを、toolchain 解決と呼びます。
最上位のターゲット
ビルド ターゲットは、Bazel コマンドラインからリクエストされた場合、最上位です。たとえば、//:foo が //:bar に依存していて、bazel build //:foo が呼び出される場合は、このビルドで //:foo は最上位で、//:bar は最上位ではありません。ただし、両方のターゲットをビルドする必要があります。最上位ターゲットと最上位以外のターゲットの重要な違いは、Bazel コマンドライン（または .bazelrc 経由）で設定されたコマンドフラグが、最上位ターゲットの構成を設定しますが、最上位以外のターゲットの遷移によって変更される可能性がある点です。
移行
ある値から別の値への構成状態のマッピング。ビルドグラフ内のターゲットが、同じルールからインスタンス化された場合でも、異なる構成を持つことができます。遷移の一般的な用途は、分割遷移です。ターゲット グラフの特定の部分がフォークされ、各フォークに異なる構成が設定されます。たとえば、1 つのビルドで分割遷移を使用して、ARM と x86 用にコンパイルされたネイティブ バイナリを含む Android APK をビルドできます。
関連情報: ユーザー定義の遷移
ツリー アーティファクト
ファイルのコレクションを表すアーティファクト。これらのファイル自体はアーティファクトではないため、それらを操作するアクションは、代わりにツリー アーティファクトを入力または出力として登録する必要があります。
公開設定
ビルドシステムで不要な依存関係を防ぐための 2 つのメカニズムのいずれかです。ターゲットの公開設定は、ターゲットが他のターゲットによって依存されるかどうかを制御します。読み込みの公開設定は、BUILD ファイルまたは .bzl ファイルが特定の .bzl ファイルを読み込むかどうかを制御します。コンテキストがない場合、通常「可視性」はターゲットの可視性を指します。
関連情報: 公開設定に関するドキュメント
ワークスペース
すべての Bazel コマンドで共有される環境は、同じメイン リポジトリから実行されます。
歴史的に、「リポジトリ」と「ワークスペース」の概念は混同されてきました。「ワークスペース」という用語は、メイン リポジトリを指すためによく使用され、「リポジトリ」の同義語として使用されることもあります。明確にするために、このような使用は避けてください。