Build イベント プロトコル (BEP)を使用すると、サードパーティ プログラムは Bazel 呼び出しに関する分析情報を取得できます。対象 たとえば、BEP を使用して IDE の情報を収集し、 ビルド結果を表示するダッシュボードを使用できます。
プロトコルは、 バッファ メッセージをいくつか セマンティクスが定義されます。ビルドとテストに関する情報が含まれています。 結果、ビルドの進捗状況、ビルド構成などを確認できます。BEP の仕組みは次のとおりです。 Bazel のコードを解析および変換し、 過去のことが出力されます。
Build Event Protocol は、ビルドに関する情報をイベントとして表します。 ビルドイベントは、ビルドイベント識別子、 子イベントの識別子のセット、ペイロードです。
Build Event Identifier: ビルドイベントの種類によっては、 不透明 文字列 または構造化 情報 ビルドイベントの詳細が出力されますビルドイベント ID は、プロジェクト内で できます。
子: ビルドイベントでは、 その子のビルドイベント識別子に フィールド。 たとえば、
PatternExpanded
ビルドイベントは、拡張するターゲットを通知します。 制限されます。このプロトコルでは、最初のイベントを除くすべてのイベントが 前のイベントで通知されるイベントです。ペイロード: ペイロードには、ビルドイベントに関する構造化された情報が含まれます。 そのイベントに固有のプロトコル バッファ メッセージとしてエンコードされます。なお、 ペイロードは想定されるタイプではないものの、
Aborted
メッセージである場合があります ビルドが早期に中止された場合です。
イベントグラフを作成する
すべてのビルドイベントは、その親と子を通る有向非巡回グラフを形成する あります。最初のビルドイベントを除くすべてのビルドイベントに、 追加することもできます。なお、子イベントの親イベントの中には、 必ず事前に投稿します。ビルドが完了したとき(成功または失敗) すべてのイベントが投稿されます。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 イベント
サービス
Protocol は、ビルドイベントを公開するための汎用 gRPC サービスです。Build イベント
サービス プロトコルは BEP とは独立しており、BEP イベントを不透明なバイトとして扱います。
Bazel には、Build Event Service プロトコルの gRPC クライアント実装が付属しています。
Build Event Protocol イベントを発行しますエンドポイントを指定して
--bes_backend=HOST:PORT
フラグを使用します。バックエンドで gRPC を使用する場合は
アドレスの先頭に適切なスキームを付ける必要があります(平文の場合は grpc://
)。
TLS を有効にした gRPC 用の 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 にはログファイル(test.log、test.xml、 Bazel が実行されているマシンに保存されているデータ)です。リモート BES サーバー ファイルが別のマシン上にあるため、通常はアクセスできません。Google の この問題を回避するには、Bazel で リモート キャッシュ保存について説明します。 Bazel は、すべての出力ファイル(ファイルを含む)をリモート キャッシュにアップロードします。 BEP で参照されているファイル)を取得すると、BES サーバーが参照先のファイルを取得できます。 キャッシュから取り出します。
詳しくは、GitHub の問題 3689 をご覧ください。 詳しく見ていきます