BEP イベントタイプごとに独自のセマンティクスがあり、最小限の内容は build_event_stream.proto に記載されています。次の用語集では、各イベントタイプについて説明します。
中止
他のイベントとは異なり、Aborted イベントは他のタイプのイベントを置換するため、対応する ID タイプはありません。Abortedこのイベントは、ビルドが早期に終了し、その下に表示されるイベント ID が正常に生成されていないことを示します。Aborted には、ビルドが完了しなかった理由を説明する列挙型とわかりやすい説明が含まれています。
たとえば、ユーザーが Bazel を中断したときにビルドがターゲットを評価している場合、BEP には次のようなイベントが含まれます。
{
"id": {
"targetCompleted": {
"label": "//:foo",
"configuration": {
"id": "544e39a7f0abdb3efdd29d675a48bc6a"
}
}
},
"aborted": {
"reason": "USER_INTERRUPTED"
}
}
ActionExecuted
ビルド内の特定のアクションの実行に関する詳細を提供します。デフォルトでは、このイベントは失敗したアクションの BEP に含まれ、ビルドエラーの根本原因を特定できるようにします。ユーザーは --build_event_publish_all_actions フラグを設定して、すべての ActionExecuted イベントを含めることができます。
ビルド終了
コマンドの完了後、コマンドの終了コードを含む単一の BuildFinished イベントが送信されます。このイベントは、信頼できる成功/失敗情報を提供します。
BuildMetadata
--build_metadata フラグの解析された内容が含まれます。このイベントは、外部データ（識別子など）を配管して Bazel と他のツールの統合をサポートするためのものです。
BuildMetrics
各コマンドの最後に単一の BuildMetrics イベントが送信され、コマンド中のビルドツールの動作を数値化するのに有用なカウンタ/ゲージが含まれます。これらの指標は実際に行われた処理を示し、再利用されたキャッシュされた処理はカウントされません。
コマンドの実行中に Java ガベージ コレクションがない場合、memory_metrics に値は入力されないことがあります。ユーザーが --memory_profile=/dev/null オプションを設定すると、コマンドの最後にガベージ コレクタが実行され、memory_metrics にデータが入力されます。
{
"id": {
"buildMetrics": {}
},
"buildMetrics": {
"actionSummary": {
"actionsExecuted": "1"
},
"memoryMetrics": {},
"targetMetrics": {
"targetsLoaded": "9",
"targetsConfigured": "19"
},
"packageMetrics": {
"packagesLoaded": "5"
},
"timingMetrics": {
"cpuTimeInMs": "1590",
"wallTimeInMs": "359"
}
}
}
BuildStarted
BEP ストリームの最初のイベント BuildStarted には、意味のある処理が始まる前にコマンドを記述するメタデータが含まれます。
BuildToolLogs
コマンドの最後に単一の BuildToolLogs イベントが送信されます。これには、ビルドツールの動作の理解やデバッグに役立つビルドツールによって生成されたファイルの URI が含まれます。一部の情報はインラインで表示できます。
{
"id": {
"buildToolLogs": {}
},
"lastMessage": true,
"buildToolLogs": {
"log": [
{
"name": "elapsed time",
"contents": "MC4xMjEwMDA="
},
{
"name": "process stats",
"contents": "MSBwcm9jZXNzOiAxIGludGVybmFsLg=="
},
{
"name": "command.profile.gz",
"uri": "file:///tmp/.cache/bazel/_bazel_foo/cde87985ad0bfef34eacae575224b8d1/command.profile.gz"
}
]
}
}
CommandLine
BEP には、すべてのコマンドライン引数（オプションや解釈されない引数を含む）の表現を含む複数の CommandLine イベントが含まれています。各 CommandLine イベントの StructuredCommandLineId には、伝達する表現を示すラベルが付きます。このようなイベントは 3 つ BEP に表示されます。
"original": Bazel が Bazel クライアントから受け取ったコマンドラインのスタートアップ オプションは、.rc ファイルから取得されません。"canonical": .rc ファイルを展開し、呼び出しポリシーを適用した有効なコマンドライン。"tool":--experimental_tool_command_lineオプションからデータが入力されます。これは、Bazel を BEP でラップするツールのコマンドラインを伝えるのに役立ちます。 これは、直接使用される base64 エンコードされたCommandLineバイナリ プロトコル バッファ メッセージか、解析されては解釈されない文字列です（ツールのオプションは Bazel のオプションとは異なる場合があります）。
設定
ビルドのトップレベル ターゲットで使用される configuration ごとに、Configuration イベントが送信されます。少なくとも 1 つの構成イベントが常に存在します。id は、TargetConfigured および TargetComplete イベント ID で再利用されます。マルチ構成ビルドでは、曖昧さを解消するために必要です。
{
"id": {
"configuration": {
"id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
}
},
"configuration": {
"mnemonic": "k8-fastbuild",
"platformName": "k8",
"cpu": "k8",
"makeVariable": {
"COMPILATION_MODE": "fastbuild",
"TARGET_CPU": "k8",
"GENDIR": "bazel-out/k8-fastbuild/bin",
"BINDIR": "bazel-out/k8-fastbuild/bin"
}
}
}
有用なシンボリック リンク
試験運用。--experimental_convenience_symlinks_bep_event オプションが設定されている場合、ワークスペース内のシンボリック リンクの管理方法を示す build コマンドによって、単一の ConvenienceSymlinksIdentified イベントが生成されます。これにより、Bazel をリモートで呼び出すツールをビルドして、Bazel をローカルで実行した場合と同様にローカル ワークスペースを配置できます。
{
"id": {
"convenienceSymlinksIdentified":{}
},
"convenienceSymlinksIdentified": {
"convenienceSymlinks": [
{
"path": "bazel-bin",
"action": "CREATE",
"target": "execroot/google3/bazel-out/k8-fastbuild/bin"
},
{
"path": "bazel-genfiles",
"action": "CREATE",
"target": "execroot/google3/bazel-out/k8-fastbuild/genfiles"
},
{
"path": "bazel-out",
"action": "CREATE",
"target": "execroot/google3/bazel-out"
}
]
}
}
フェッチ
コマンド実行の一環としてフェッチ オペレーションが発生したことを示します。他のイベントとは異なり、キャッシュに保存された取得結果が再利用された場合、このイベントは BEP ストリームに表示されません。
NamedSetOfFiles
NamedSetOfFiles イベントは、コマンド評価中に生成されたファイルの depset と一致する構造を報告します。推移的に含まれているデプセットは NamedSetOfFilesId によって識別されます。
ストリームの NamedSetOfFiles イベントの解釈方法については、BEP の例のページをご覧ください。
OptionsParsed
1 つの OptionsParsed イベントで、コマンドに適用されたすべてのオプションがリストされ、起動オプションとコマンド オプションが分離されます。また、必要に応じて InvocationPolicy も含まれています。
{
"id": {
"optionsParsed": {}
},
"optionsParsed": {
"startupOptions": [
"--max_idle_secs=10800",
"--noshutdown_on_low_sys_mem",
"--connect_timeout_secs=30",
"--output_user_root=/tmp/.cache/bazel/_bazel_foo",
"--output_base=/tmp/.cache/bazel/_bazel_foo/a61fd0fbee3f9d6c1e30d54b68655d35",
"--deep_execroot",
"--expand_configs_in_place",
"--idle_server_tasks",
"--write_command_log",
"--nowatchfs",
"--nofatal_event_bus_exceptions",
"--nowindows_enable_symlinks",
"--noclient_debug",
],
"cmdLine": [
"--enable_platform_specific_config",
"--build_event_json_file=/tmp/bep.json"
],
"explicitCmdLine": [
"--build_event_json_file=/tmp/bep.json"
],
"invocationPolicy": {}
}
}
パターンを開きました
PatternExpanded イベントは、コマンドラインで指定されたパターンに一致するすべてのターゲットのセットを示します。コマンドが成功すると、PatternExpandedId のすべてのパターンと PatternExpanded イベントの子のすべてのターゲットを持つ単一のイベントが生成されます。パターンが test_suite のいずれかに拡張される場合、test_suite に含まれる一連のテスト ターゲット。解決に失敗したパターンごとに、BEP にはパターンを識別する PatternExpandedId を持つ追加の Aborted イベントが含まれています。
{
"id": {
"pattern": {
"pattern":["//base:all"]
}
},
"children": [
{"targetConfigured":{"label":"//base:foo"}},
{"targetConfigured":{"label":"//base:foobar"}}
],
"expanded": {
"testSuiteExpansions": {
"suiteLabel": "//base:suite",
"testLabels": "//base:foo_test"
}
}
}
Progress
進行状況イベントには、コマンドの実行中に Bazel が生成した標準出力と標準エラーが含まれます。これらのイベントは、論理的な「親」イベント（特に NamedSetOfFiles）によってまだ通知されていないイベントを通知するために必要な場合にも自動生成されます。
ターゲット完了
実行フェーズを完了する (target, configuration, aspect) の組み合わせごとに、TargetComplete イベントが BEP に含まれます。イベントには、ターゲットの成功/失敗と、ターゲットにリクエストされた出力グループが含まれます。
{
"id": {
"targetCompleted": {
"label": "//examples/py:bep",
"configuration": {
"id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
}
}
},
"completed": {
"success": true,
"outputGroup": [
{
"name": "default",
"fileSets": [
{
"id": "0"
}
]
}
]
}
}
ターゲット構成済み
分析フェーズを完了するターゲットごとに、BEP に TargetConfigured イベントが追加されます。これは、ターゲットの「ルールの種類」属性の信頼できるソースです。ターゲットに適用された構成は、イベントの発表された子に表示されます。
たとえば、--experimental_multi_cpu オプションを使用してビルドすると、2 つの構成を持つ単一のターゲットに対して次の TargetConfigured イベントが生成されます。
{
"id": {
"targetConfigured": {
"label": "//starlark_configurations/multi_arch_binary:foo"
}
},
"children": [
{
"targetCompleted": {
"label": "//starlark_configurations/multi_arch_binary:foo",
"configuration": {
"id": "c62b30c8ab7b9fc51a05848af9276529842a11a7655c71327ade26d7c894c818"
}
}
},
{
"targetCompleted": {
"label": "//starlark_configurations/multi_arch_binary:foo",
"configuration": {
"id": "eae0379b65abce68d54e0924c0ebcbf3d3df26c6e84ef7b2be51e8dc5b513c99"
}
}
}
],
"configured": {
"targetKind": "foo_binary rule"
}
}
ターゲットの概要
実行される (target, configuration) ペアごとに、構成されたターゲットの実行と、その構成済みターゲットに適用されたすべての側面を含む集計成功結果とともに TargetSummary イベントが含まれます。
TestResult
テストがリクエストされると、テストごとに、シャードと実行ごとに TestResult イベントが送信されます。これにより、BEP コンシューマはテストに失敗したテスト アクションを正確に識別し、各テスト アクションのテスト出力（ログ、test.xml ファイルなど）を識別できます。
テストの概要
テストがリクエストされると、テスト (target,
configuration) ごとに TestSummary イベントが送信されます。これにはテストの結果の解釈に必要な情報が含まれます。テストあたりの試行回数、シャード数、実行数が含まれているため、BEP コンシューマーはこれらのディメンションでアーティファクトを区別できます。テストごとの試行と実行は、FLAKY テストと FAILED テストを区別するために TestStatus の集計を生成するときに考慮されます。
非構造化コマンドライン
CommandLine とは異なり、このイベントでは、すべての .bazelrc ファイルを展開して --config フラグを検討した後、ビルドツールで検出される未解析のコマンドライン フラグが文字列形式で送信されます。
特定のコマンドの実行を正確に再現するには、UnstructuredCommandLine イベントを使用してください。
Workspace の設定
単一の WorkspaceConfig イベントには、実行ルートなどのワークスペースに関する構成情報が含まれます。
ワークスペースのステータス
1 つの WorkspaceStatus イベントには、ワークスペースのステータス コマンドの結果が含まれます。