2025 年 BazelCon 报名和 CFP 现已开放！

此页面由 Cloud Translation API 翻译。

Build Event Protocol 术语表

报告问题查看源代码每夜版 · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

每种 BEP 事件类型都有自己的语义，这些语义至少在 build_event_stream.proto 中有记录。以下词汇表介绍了每种事件类型。

已中止

与其他事件不同，Aborted 没有对应的 ID 类型，因为 Aborted 事件会替换其他类型的事件。此事件表示 build 已提前终止，并且其显示的事件 ID 未正常生成。Aborted 包含一个枚举和直观易懂的说明，用于解释为何 build 未完成。

例如，如果 build 在用户中断 Bazel 时正在评估目标，则 BEP 会包含如下事件：

{
  "id": {
    "targetCompleted": {
      "label": "//:foo",
      "configuration": {
        "id": "544e39a7f0abdb3efdd29d675a48bc6a"
      }
    }
  },
  "aborted": {
    "reason": "USER_INTERRUPTED"
  }
}

ActionExecuted

提供有关 build 中特定 Action 执行的详细信息。默认情况下，此事件仅针对失败的操作包含在 BEP 中，以支持识别 build 失败的根本原因。用户可以设置 --build_event_publish_all_actions 标志来包含所有 ActionExecuted 事件。

BuildFinished

命令完成后，系统会发送一个 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 中都有一个标签，用于指明该事件传达的是哪种表示形式；BEP 中显示了三个此类事件：

"original"：从 Bazel 客户端接收到的重建命令行，不包含从 .rc 文件获取的启动选项。
"canonical"：展开 .rc 文件并应用调用政策后的有效命令行。
"tool"：从 --experimental_tool_command_line 选项填充。这有助于通过 BEP 传达封装 Bazel 的工具的命令行。这可以是直接使用的 base64 编码的 CommandLine 二进制协议缓冲区消息，也可以是已解析但未解释的字符串（因为工具的选项可能与 Bazel 的选项不同）。

配置

对于 build 中顶级目标中的每个 configuration，系统都会发送一个 Configuration 事件。至少会存在一个配置事件。id 可供 TargetConfigured 和 TargetComplete 事件 ID 重用，对于在多配置 build 中消除这些事件的歧义是必需的。

{
  "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"
    }
  }
}

ConvenienceSymlinksIdentified

实验性 - 如果设置了 --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 相匹配的结构。以传递方式包含的 depsets 由 NamedSetOfFilesId 标识。

如需详细了解如何解读数据流的 NamedSetOfFiles 事件，请参阅 BEP 示例页面。

OptionsParsed

单个 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

PatternExpanded 事件表示与命令行中提供的模式匹配的所有目标。对于成功的命令，会有一个包含 PatternExpandedId 中所有模式和 PatternExpanded 事件的 children 中所有目标对象的事件。如果该模式扩展为任何 test_suite，则为 test_suite 所包含的测试目标集。对于每个无法解析的模式，BEP 都包含一个额外的 Aborted 事件，其中包含一个用于标识相应模式的 PatternExpandedId。

{
  "id": {
    "pattern": {
      "pattern":["//base:all"]
    }
  },
  "children": [
    {"targetConfigured":{"label":"//base:foo"}},
    {"targetConfigured":{"label":"//base:foobar"}}
  ],
  "expanded": {
    "testSuiteExpansions": {
      "suiteLabel": "//base:suite",
      "testLabels": "//base:foo_test"
    }
  }
}

进度

进度事件包含 Bazel 在命令执行期间生成的标准输出和标准错误。这些事件也会根据需要自动生成，以公布尚未由逻辑“父”事件（尤其是 NamedSetOfFiles）公布的事件。

TargetComplete

对于完成执行阶段的每个 (target, configuration, aspect) 组合，BEP 中都会包含一个 TargetComplete 事件。该事件包含目标的成功/失败情况以及目标请求的输出组。

{
  "id": {
    "targetCompleted": {
      "label": "//examples/py:bep",
      "configuration": {
        "id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
      }
    }
  },
  "completed": {
    "success": true,
    "outputGroup": [
      {
        "name": "default",
        "fileSets": [
          {
            "id": "0"
          }
        ]
      }
    ]
  }
}

TargetConfigured

对于完成分析阶段的每个目标，BEP 中都会包含一个 TargetConfigured 事件。这是目标“规则类型”属性的权威来源。应用于目标的配置会显示在已公布的事件的 children 中。

例如，使用 --experimental_multi_cpu 选项进行构建可能会针对具有两种配置的单个目标生成以下 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"
  }
}

TargetSummary

对于执行的每个 (target, configuration) 对，系统都会包含一个 TargetSummary 事件，其中包含涵盖配置的目标的执行情况以及应用于该配置的目标的所有方面的汇总成功结果。

TestResult

如果请求进行测试，则会针对每次测试尝试、每个分片和每次测试运行发送一个 TestResult 事件。这样一来，BEP 使用者就可以准确识别哪些测试操作未通过测试，并识别每个测试操作的测试输出（例如日志、test.xml 文件）。

TestSummary

如果请求进行测试，则会针对每个测试 (target, configuration) 发送一个 TestSummary 事件，其中包含解读测试结果所需的信息。其中包含每次测试的尝试次数、分片数和运行次数，以便 BEP 使用者区分这些维度上的制品。在生成汇总 TestStatus 时，系统会考虑每次测试的尝试次数和运行次数，以区分 FLAKY 测试和 FAILED 测试。

UnstructuredCommandLine

与 CommandLine 不同，此事件以字符串形式携带未解析的命令行标志，这些标志是构建工具在展开所有 .bazelrc 文件并考虑 --config 标志后遇到的。

UnstructuredCommandLine 事件可用于精确重现给定的命令执行。

WorkspaceConfig

单个 WorkspaceConfig 事件包含有关工作区的配置信息，例如执行根目录。

WorkspaceStatus

单个 WorkspaceStatus 事件包含工作区状态命令的结果。

Build Event Protocol 术语表 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

已中止