Build Event Protocol（BEP）を使用すると、サードパーティのプログラムが Bazel の呼び出しに関する分析情報を取得できます。たとえば、BEP を使用して、ビルド結果を表示する IDE プラグインやダッシュボードの情報を収集できます。
プロトコルは、いくつかのセマンティクスが定義された一連のプロトコル バッファ メッセージです。ビルドとテスト結果、ビルドの進行状況、ビルド構成などに関する情報が含まれています。BEP はプログラムで使用することが想定されており、Bazel のコマンドライン出力の解析を過去のものにします。
Build Event Protocol は、ビルドに関する情報をイベントとして表します。ビルドイベントは、ビルドイベント識別子、子イベント識別子のセット、ペイロードで構成されるプロトコル バッファ メッセージです。
ビルドイベント識別子: ビルドイベントの種類に応じて、ビルドイベントの詳細を示す不透明な文字列または構造化情報になります。ビルドイベント識別子はビルド内で一意です
子: ビルドイベントは、子フィールドにビルドイベント 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 サービスです。Build Event Service プロトコルは BEP とは独立しており、BEP イベントを不透明なバイトとして扱います。Bazel には、Build Event Protocol イベントを公開する Build Event Service プロトコルの gRPC クライアント実装が付属しています。--bes_backend=HOST:PORT フラグを使用して、イベントを送信するエンドポイントを指定できます。バックエンドで gRPC を使用する場合は、アドレスの先頭に適切なスキームを付ける必要があります（平文の gRPC の場合は grpc://、TLS を有効にした gRPC の場合は grpcs://）。
ビルドイベント サービスのフラグ
Bazel には、Build Event Service プロトコルに関連する次のようなフラグがあります。
--bes_backend--[no]bes_best_effort--[no]bes_lifecycle_events--bes_results_url--bes_timeout--project_id
これらのフラグの詳細については、コマンドライン リファレンスをご覧ください。
認証とセキュリティ
Bazel の Build Event Service の実装は、認証と TLS もサポートしています。これらの設定は、以下のフラグを使用して制御できます。なお、これらのフラグは Bazel のリモート実行でも使用されます。これは、ビルド イベント サービスとリモート実行エンドポイントが同じ認証と TLS インフラストラクチャを共有する必要があることを意味します。
--[no]google_default_credentials--google_credentials--google_auth_scopes--tls_certificate--[no]tls_enabled
これらのフラグの詳細については、コマンドライン リファレンスをご覧ください。
ビルドイベント サービスとリモート キャッシュ
通常、BEP には、Bazel が実行されているマシンに保存されているログファイル（test.log、test.xml など）への参照が多数含まれています。これらのファイルは別のマシン上にあるため、リモート BES サーバーは通常、これらのファイルにアクセスできません。この問題を回避するには、Bazel でリモート キャッシュを使用します。Bazel は、すべての出力ファイル（BEP で参照されているファイルを含む）にすべての出力ファイルをアップロードし、BES サーバーはキャッシュから参照ファイルを取得できます。
詳しくは、GitHub の問題 3689 をご覧ください。