Build Event Protocol （BEP）を使用すると、サードパーティ プログラムで Bazel の呼び出しに関する分析情報を取得できます。たとえば、BEP を使用して、IDE プラグインやビルド結果を表示するダッシュボードの情報を収集できます。
このプロトコルは、プロトコル バッファ メッセージのセットであり、その上に セマンティクスが定義されています。ビルドとテストの結果、ビルドの進行状況、ビルド構成などの情報が含まれます。BEP はプログラムで利用することを目的としており、Bazel のコマンドライン出力を解析する必要がなくなります。
Build Event Protocol は、ビルドに関する情報をイベントとして表します。ビルドイベントは、ビルドイベント識別子、子イベント識別子のセット、ペイロードで構成されるプロトコル バッファ メッセージです。
ビルドイベント識別子: ビルドイベントの種類に応じて、 不透明な 文字列 または構造化された 情報 になります。ビルドイベント識別子は、ビルド内で一意です。
子: ビルドイベントは、 子フィールドにビルドイベント識別子を含めることで、他のビルドイベントを通知できます。 たとえば、
PatternExpandedビルドイベントは、展開先のターゲットを子として通知します。このプロトコルでは、最初のイベントを除くすべてのイベントが、前のイベントによって通知されることが保証されています。ペイロード: ペイロードには、ビルドイベントに関する構造化された情報が含まれています。この情報は、そのイベントに固有のプロトコル バッファ メッセージとしてエンコードされます。ビルドが途中で中止された場合、ペイロードは想定されるタイプではなく、
Abortedメッセージになることがあります。
ビルドイベント グラフ
すべてのビルドイベントは、親と子の関係を通じて有向非巡回グラフを形成します。最初のビルドイベントを除くすべてのビルドイベントには、1 つ以上の親イベントがあります。子イベントの親イベントが、子イベントの前に投稿されるとは限りません。ビルドが完了すると（成功または失敗）、通知されたすべてのイベントが投稿されます。Bazel のクラッシュやネットワーク転送の失敗が発生した場合、通知されたビルドイベントが投稿されないことがあります。
イベントグラフの構造は、 コマンドのライフサイクルを反映しています。すべての BEP グラフには、次のような特徴的な形状があります。
- ルートイベントは常に
BuildStartedイベントです。他のすべてのイベントはその子孫です。 - BuildStarted イベントの直接の子には、 コマンドに関するメタデータが含まれます。
- ビルドされたファイルやテスト
結果など、 コマンドによって生成されたデータを含むイベントは、
BuildFinishedイベントの前に表示されます。 BuildFinishedイベントの後に、ビルドに関する概要情報（指標データやプロファイリング データなど）を含むイベントが続くことがあります。
Build Event Protocol を使用する
バイナリ形式で使用する
BEP をバイナリ形式で使用するには:
Bazel でプロトコル バッファ メッセージをファイルにシリアル化するには、
--build_event_binary_file=/path/to/fileオプションを指定します。ファイルには、シリアル化されたプロトコル バッファ メッセージが含まれます。各メッセージは長さで区切られます。 各メッセージには、可変長整数としてエンコードされた長さが接頭辞として付加されます。 この形式は、プロトコル バッファ ライブラリのparseDelimitedFrom(InputStream)メソッドを使用して読み取ることができます。次に、シリアル化されたプロトコル バッファ メッセージから関連情報を抽出するプログラムを作成します。
テキスト形式または JSON 形式で使用する
次の Bazel コマンドライン フラグを指定すると、BEP がテキストや JSON などの人間が読める形式で出力されます。
--build_event_text_file
--build_event_json_file
Build Event Service
Build Event
Service
Protocol は、ビルドイベントを公開するための汎用 gRPC サービスです。Build Event Service プロトコルは BEP とは独立しており、BEP イベントを不透明なバイトとして扱います。
Bazel には、Build Event Protocol イベントを公開する Build Event Service プロトコルの gRPC クライアント実装が付属しています。イベントの送信先のエンドポイントは、--bes_backend=HOST:PORT フラグを使用して指定できます。バックエンドで gRPC を使用する場合は、アドレスの先頭に適切なスキームを追加する必要があります。プレーンテキスト gRPC の場合は grpc://、TLS が有効な gRPC の場合は grpcs:// です。
Build Event Service フラグ
Bazel には、Build Event Service プロトコルに関連するフラグがいくつかあります。
--bes_backend--[no]bes_lifecycle_events--bes_results_url--bes_timeout--bes_instance_name
各フラグの説明については、 コマンドライン リファレンスをご覧ください。
認証とセキュリティ
Bazel の Build Event Service 実装では、認証と TLS もサポートされています。 これらの設定は、次のフラグを使用して制御できます。これらのフラグは、Bazel のリモート実行にも使用されます。つまり、Build Event Service エンドポイントとリモート実行エンドポイントは、同じ認証インフラストラクチャと TLS インフラストラクチャを共有する必要があります。
--[no]google_default_credentials--google_credentials--google_auth_scopes--tls_certificate--[no]tls_enabled
各フラグの説明については、 コマンドライン リファレンスをご覧ください。
Build Event Service とリモート キャッシュ
通常、BEP には、Bazel が実行されているマシンに保存されているログファイル（test.log、test.xml など）への参照が多数含まれています。リモート BES サーバーは、通常、これらのファイルにアクセスできません。これらのファイルは別のマシンに保存されているためです。この問題を回避するには、リモート キャッシュで Bazel を使用します。Bazel はすべての出力ファイルをリモート キャッシュにアップロードします（BEP で参照されているファイルを含む）。BES サーバーは、キャッシュから参照されているファイルを取得できます。
詳細については、GitHub の問題 3689 を ご覧ください。