Build Event Protocol（BEP）により、サードパーティ プログラムは Bazel 呼び出しの分析情報を取得できます。たとえば、BEP を使用して、ビルド結果を表示する IDE プラグインやダッシュボードの情報を収集できます。
プロトコルは、その上にいくつかのセマンティクスが定義されたプロトコル バッファ メッセージのセットです。これには、ビルドとテスト結果、ビルドの進行状況、ビルド構成などに関する情報が含まれます。BEP はプログラムによって使用されることを意図しており、Bazel のコマンドライン出力の解析は過去のものになります。
ビルドイベント プロトコルは、ビルドに関する情報をイベントとして表します。ビルドイベントは、ビルドイベント識別子、子イベント識別子のセット、ペイロードで構成されるプロトコル バッファ メッセージです。
ビルドイベント識別子: ビルドイベントの種類に応じて、ビルドイベントに関する詳細情報を示す不透明な文字列や構造化された情報などが該当します。ビルドイベント識別子は、ビルド内で一意です。
子: ビルドイベントは、その子フィールドにビルドイベント識別子を含めることで、他のビルドイベントを通知できます。たとえば、
PatternExpandedビルドイベントにより、展開先のターゲットが子としてアナウンスされます。プロトコルは、最初のイベントを除くすべてのイベントが前のイベントによってアナウンスされることを保証します。ペイロード: ペイロードには、ビルドイベントに関する構造化された情報が含まれ、そのイベントに固有のプロトコル バッファ メッセージとしてエンコードされます。ペイロードが期待されるタイプではない場合もありますが、ビルドが早期に中止された場合は
Abortedメッセージになることがあります。
イベントグラフを作成する
すべてのビルドイベントは、親と子の関係を介して有向非巡回グラフを形成します。最初のビルドイベントを除くすべてのビルド イベントには、1 つ以上の親イベントがあります。子イベントの親イベントを必ずしも投稿する必要はありません。ビルドが完了すると（成功または失敗）、通知されたすべてのイベントが投稿されます。Bazel のクラッシュやネットワーク転送の失敗が発生した場合、通知されたビルドイベントが投稿されないことがあります。
イベントグラフの構造はコマンドのライフサイクルを反映しています。すべての BEP グラフの特徴は次のとおりです。
- ルートイベントは常に
BuildStartedイベントです。他のすべてのイベントは、その子孫です。 - BuildStarted イベントの直接の子には、コマンドに関するメタデータが含まれています。
- ビルドされたファイルやテスト結果など、コマンドによって生成されたデータを含むイベントは、
BuildFinishedイベントの前に表示されます。 BuildFinishedイベントの後に、ビルドに関する概要情報（指標やプロファイリング データなど）を含むイベントを続けることができます。
ビルド イベント プロトコルの使用
バイナリ形式で使用する
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://）をプレフィックスとして付ける必要があります。
Build Event Service フラグ
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 のリモート実行にも使用されます。つまり、Build Event Service と Remote Execution エンドポイントは、同じ認証と 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 をご覧ください。