アクション
ビルド中に実行するコマンド（アーティファクトを入力として受け取り、他のアーティファクトを出力として生成するコンパイラの呼び出しなど）。コマンドライン引数、アクションキー、環境変数、宣言された入出力アーティファクトなどのメタデータが含まれます。
関連情報: ルールに関するドキュメント
アクション キャッシュ
実行されたアクションと、そのアクションが作成した出力とのマッピングを保存するディスク上のキャッシュ。キャッシュキーはアクションキーと呼ばれます。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
アーティファクトをご覧ください。
密閉性
ビルドとテストのオペレーションに外部からの影響がない場合、ビルドは密閉型であるため、結果が確定的で正しいものになります。たとえば、密閉型のビルドでは通常、アクションへのネットワーク アクセスを禁止し、宣言された入力へのアクセスを制限し、固定のタイムスタンプとタイムゾーンを使用し、環境変数へのアクセスを制限し、乱数ジェネレータに固定シードを使用します。
増分ビルド
増分ビルドでは、以前のビルドの結果を再利用して、ビルド時間とリソース使用量を削減します。依存関係のチェックとキャッシュ保存の目的は、このタイプのビルドに対して正しい結果を生成することです。増分ビルドはクリーンビルドの逆です。
ラベル
ターゲットの識別子。通常、形式は @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 で実装されているルール。このようなルールは、ネイティブ モジュール（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 ビルドで使用できるソースファイルを含むディレクトリ ツリー。多くの場合、リポのために短縮されます。
リポジトリ境界マーカー ファイルは、MODULE.bazel（このリポジトリが Bazel モジュールを表すことを示します）、REPO.bazel、または以前のコンテキストでは WORKSPACE または WORKSPACE.bazel にできます。リポジトリ境界マーカー ファイルは、リポジトリの境界を示します。このようなファイルは、1 つのディレクトリに共存できます。
メイン リポジトリは、現在の Bazel コマンドが実行されているリポジトリです。
外部リポジトリを定義するには、MODULE.bazel ファイルでモジュールを指定するか、モジュール拡張機能でリポルールを呼び出します。オンデマンドでディスク上の所定の「魔法の」場所にフェッチできます。
各リポジトリには一意で一定の「正規」名が付いていますが、他のリポジトリから見た場合の「見かけ」名が異なる場合があります。
関連情報: 外部依存関係の概要
リポジトリ キャッシュ
ビルドのために Bazel によってダウンロードされたファイルのコンテンツ アドレス指定可能な共有キャッシュ。ワークスペース間で共有できます。初回ダウンロード後のオフライン ビルドを有効にします。http_archive などのリポジトリ ルールや repository_ctx.download などのリポジトリ ルール API を介してダウンロードしたファイルをキャッシュに保存するためによく使用されます。ダウンロードに SHA-256 チェックサムが指定されている場合にのみ、ファイルがキャッシュに保存されます。
リポジトリ ルール
リポジトリを実体化（またはフェッチ）する方法を Bazel に指示するリポジトリ定義のスキーマ。多くの場合、単にリポルールのため短縮されます。Repo ルールは、モジュールを基盤とするリポジトリを定義するために Bazel によって内部で呼び出されます。また、モジュール拡張機能によって呼び出すこともできます。Repo ルールは、インターネットへのアクセスやファイル I/O を実行できます。最も一般的なリポジトリ ルールは、インターネットからソースファイルを含むアーカイブをダウンロードする http_archive です。
関連情報: Repo ルールのドキュメント
再現性
時間、メソッド、環境に関係なく、ビルドまたはテストへの入力セットが毎回同じ出力セットを生成するという、ビルドまたはテストのプロパティ。これは、必ずしも出力が正しい出力または目的の出力であることを意味するわけではありません。
ルール
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 ファイルを読み込めるかどうかを制御する読み込みの可視性。コンテキストがなければ、通常、「可視性」はターゲットの可視性を指します。
関連情報: 公開設定に関するドキュメント
ワークスペース
すべての Bazel コマンドで共有される環境は、同じメイン リポジトリから実行されます。
これまで、「リポジトリ」と「ワークスペース」のコンセプトは混同されてきました。「ワークスペース」という用語はメイン リポジトリを指すために使用され、場合によっては「リポジトリ」の同義語として使用されることさえあります。明確にするために、このような使用は避けてください。