Cada tipo de evento de BEP tiene su propia semántica, documentada de forma mínima en build_event_stream.proto. En el siguiente glosario, se describe cada tipo de evento.
Anulado
A diferencia de otros eventos, Aborted no tiene un tipo de ID correspondiente, ya que el evento Aborted reemplaza eventos de otros tipos. Este evento indica que la compilación se cerró antes de tiempo y que el ID de evento en el que aparece no se produjo de forma normal. Aborted contiene una enumeración y una descripción fácil de entender para explicar por qué no se completó la compilación.
Por ejemplo, si una compilación está evaluando un destino cuando el usuario interrumpe Bazel, el BEP contiene un evento como el siguiente:
{
"id": {
"targetCompleted": {
"label": "//:foo",
"configuration": {
"id": "544e39a7f0abdb3efdd29d675a48bc6a"
}
}
},
"aborted": {
"reason": "USER_INTERRUPTED"
}
}
ActionExecuted
Proporciona detalles sobre la ejecución de una acción específica en una compilación. De forma predeterminada, este evento se incluye en el BEP solo para las acciones que fallan, para ayudar a identificar la causa raíz de las fallas de compilación. Los usuarios pueden configurar la marca --build_event_publish_all_actions para incluir todos los eventos ActionExecuted.
BuildFinished
Se envía un solo evento BuildFinished después de que se completa el comando y se incluye el código de salida del comando. Este evento proporciona información confiable sobre el éxito o la falla.
BuildMetadata
Contiene el contenido analizado de la marca --build_metadata. Este evento existe para admitir la integración de Bazel con otras herramientas a través de la canalización de datos externos (como identificadores).
BuildMetrics
Se envía un solo evento BuildMetrics al final de cada comando y, además, incluye contadores o medidores útiles para cuantificar el comportamiento de la herramienta de compilación durante el comando. Estas métricas indican el trabajo que se realizó y no cuentan el trabajo almacenado en caché que se reutiliza.
Ten en cuenta que es posible que memory_metrics no se propague si no hubo una recolección de basura de Java durante la ejecución del comando. Los usuarios pueden configurar la opción --memory_profile=/dev/null, que obliga al recolector de basura a ejecutarse al final del comando para propagar memory_metrics.
{
"id": {
"buildMetrics": {}
},
"buildMetrics": {
"actionSummary": {
"actionsExecuted": "1"
},
"memoryMetrics": {},
"targetMetrics": {
"targetsLoaded": "9",
"targetsConfigured": "19"
},
"packageMetrics": {
"packagesLoaded": "5"
},
"timingMetrics": {
"cpuTimeInMs": "1590",
"wallTimeInMs": "359"
}
}
}
BuildStarted
El primer evento de un flujo de BEP, BuildStarted, incluye metadatos que describen el comando antes de que comience cualquier trabajo significativo.
BuildToolLogs
Se envía un solo evento BuildToolLogs al final de un comando, incluidos los URIs de los archivos que genera la herramienta de compilación que pueden ayudar a comprender o depurar el comportamiento de la herramienta de compilación. Es posible que se incluya cierta información intercalada.
{
"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
El BEP contiene varios eventos CommandLine que contienen representaciones de todos los argumentos de línea de comandos (incluidas las opciones y los argumentos no interpretados).
Cada evento CommandLine tiene una etiqueta en su StructuredCommandLineId que indica qué representación transmite. Tres de esos eventos aparecen en el BEP:
"original": Se reconstruyó la línea de comandos como la recibió Bazel del cliente de Bazel, sin opciones de inicio provenientes de archivos .rc."canonical": La línea de comandos efectiva con los archivos .rc expandidos y la política de invocación aplicada."tool": Se propaga desde la opción--experimental_tool_command_line. Esto es útil para transmitir la línea de comandos de una herramienta que une Bazel a través del BEP. Puede ser un mensaje de búfer de protocolo binarioCommandLinecodificado en base64 que se usa directamente o una cadena que se analiza, pero no se interpreta (ya que las opciones de la herramienta pueden diferir de las de Bazel).
Configuración
Se envía un evento Configuration para cada configuration que se usa en los destinos de nivel superior de una compilación. Siempre debe haber al menos un evento de configuración. Los IDs de eventos TargetConfigured y TargetComplete reutilizan id y son necesarios para desambiguar esos eventos en compilaciones de varias configuraciones.
{
"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. Si se establece la opción --experimental_convenience_symlinks_bep_event, los comandos build producen un solo evento ConvenienceSymlinksIdentified para indicar cómo se deben administrar los symlinks en el espacio de trabajo.
Esto permite compilar herramientas que invoquen a Bazel de forma remota y, luego, organizar el espacio de trabajo
local como si Bazel se hubiera ejecutado de forma local.
{
"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"
}
]
}
}
Recuperar
Indica que se produjo una operación de recuperación como parte de la ejecución del comando. A diferencia de otros eventos, si se vuelve a usar un resultado de recuperación almacenado en caché, este evento no aparece en el flujo de BEP.
NamedSetOfFiles
Los eventos NamedSetOfFiles informan una estructura que coincide con un depset de archivos producidos durante la evaluación del comando.
NamedSetOfFilesId identifica los conjuntos de dependencias incluidos de forma transitiva.
Para obtener más información sobre cómo interpretar los eventos NamedSetOfFiles de una transmisión, consulta la página de ejemplos de BEP.
OptionsParsed
Un solo evento OptionsParsed enumera todas las opciones aplicadas al comando y
separa las opciones de inicio de las opciones de comando. También incluye InvocationPolicy, si corresponde.
{
"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",
"--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
Los eventos PatternExpanded indican el conjunto de todos los destinos que coinciden con los patrones proporcionados en la línea de comandos. En el caso de los comandos que se ejecutan correctamente, hay un solo evento con todos los patrones en PatternExpandedId y todos los destinos en los elementos secundarios del evento PatternExpanded. Si el patrón se expande a cualquier test_suite, se incluye el conjunto de destinos de prueba que incluye test_suite. Para cada patrón que no se resuelve, el BEP contiene un evento Aborted adicional con un PatternExpandedId que identifica el patrón.
{
"id": {
"pattern": {
"pattern":["//base:all"]
}
},
"children": [
{"targetConfigured":{"label":"//base:foo"}},
{"targetConfigured":{"label":"//base:foobar"}}
],
"expanded": {
"testSuiteExpansions": {
"suiteLabel": "//base:suite",
"testLabels": "//base:foo_test"
}
}
}
Progreso
Los eventos de progreso contienen el resultado estándar y el error estándar que produce Bazel durante la ejecución del comando. Estos eventos también se generan automáticamente según sea necesario para anunciar eventos que no se anunciaron con un evento "superior" lógico (en particular, NamedSetOfFiles).
TargetComplete
Para cada combinación de (target, configuration, aspect) que completa la fase de ejecución, se incluye un evento TargetComplete en el BEP. El evento contiene
el éxito o el error del destino y los grupos de salida solicitados del destino.
{
"id": {
"targetCompleted": {
"label": "//examples/py:bep",
"configuration": {
"id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
}
}
},
"completed": {
"success": true,
"outputGroup": [
{
"name": "default",
"fileSets": [
{
"id": "0"
}
]
}
]
}
}
TargetConfigured
Para cada objetivo que completa la fase de análisis, se incluye un evento TargetConfigured en el BEP. Esta es la fuente autorizada para el atributo "tipo de regla" de un objetivo. Las configuraciones aplicadas al objetivo aparecen en los elementos secundarios anunciados del evento.
Por ejemplo, la compilación con las opciones --experimental_multi_cpu puede producir el siguiente evento TargetConfigured para un solo destino con dos configuraciones:
{
"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
Para cada par (target, configuration) que se ejecuta, se incluye un evento TargetSummary con un resultado de éxito agregado que abarca la ejecución del objetivo configurado y todos los aspectos aplicados a ese objetivo configurado.
TestResult
Si se solicita la prueba, se envía un evento TestResult para cada intento de prueba, fragmento y ejecución por prueba. Esto permite a los consumidores de BEP identificar con precisión qué acciones de prueba fallaron y los resultados de las pruebas (como registros y archivos test.xml) para cada acción de prueba.
TestSummary
Si se solicita la prueba, se envía un evento TestSummary para cada (target,
configuration) de prueba, que contiene la información necesaria para interpretar los resultados de la prueba. Se incluye la cantidad de intentos, fragmentos y ejecuciones por prueba para permitir que los consumidores de BEP diferencien los artefactos en estas dimensiones. Los intentos y las ejecuciones por prueba se consideran mientras se produce el TestStatus agregado para diferenciar las pruebas FLAKY de las pruebas FAILED.
UnstructuredCommandLine
A diferencia de CommandLine, este evento lleva las marcas de línea de comandos
sin analizar en forma de cadena, tal como las encuentra la herramienta de compilación después de expandir todos los
archivos .bazelrc y
considerar la marca --config.
Se puede confiar en el evento UnstructuredCommandLine para reproducir con precisión una ejecución de comando determinada.
WorkspaceConfig
Un solo evento WorkspaceConfig contiene información de configuración sobre el lugar de trabajo, como la raíz de ejecución.
WorkspaceStatus
Un solo evento WorkspaceStatus contiene el resultado del comando de estado del lugar de trabajo.