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