Cada tipo de evento de BEP tiene su propia semántica, documentada mínimamente 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 porque el evento Aborted reemplaza los eventos de otros tipos. Este evento indica que la compilación finalizó de forma anticipada y que el ID del evento en el que aparece no se produjo con normalidad. Aborted contiene una descripción y una descripción sencilla para explicar por qué no se completó la compilación.
Por ejemplo, si una compilación evalúa un destino cuando el usuario interrumpe Bazel, BEP contiene un evento como el siguiente:
{
"id": {
"targetCompleted": {
"label": "//:foo",
"configuration": {
"id": "544e39a7f0abdb3efdd29d675a48bc6a"
}
}
},
"aborted": {
"reason": "USER_INTERRUPTED"
}
}
Acción ejecutada
Proporciona detalles sobre la ejecución de una Action específica en una compilación. De forma predeterminada, este evento se incluye en la BEP solo para las acciones con errores a fin de identificar la causa raíz de las fallas de compilación. Los usuarios pueden establecer la marca --build_event_publish_all_actions para incluir todos los eventos ActionExecuted.
Compilación finalizada
Se envía un solo evento BuildFinished una vez que se completa el comando, y este incluye el código de salida correspondiente. Este evento proporciona información autorizada de éxito o fracaso.
Metadatos de compilación
Incluye el contenido analizado de la marca --build_metadata. Este evento existe
para admitir la integración de Bazel con otras herramientas mediante el plomería de datos externos (como
identificadores).
Métricas de compilación
Se envía un solo evento BuildMetrics al final de cada comando y, además, incluye contadores/indicadores útiles para cuantificar el comportamiento de la herramienta de compilación durante el comando. Estas métricas indican que el trabajo realmente se realizó y no cuenta el trabajo almacenado en caché que se vuelve a usar.
Ten en cuenta que es posible que memory_metrics no se propague si no hubo una recolección de elementos no utilizados de Java durante la ejecución del comando. Los usuarios pueden establecer la opción --memory_profile=/dev/null, que obliga al recolector de elementos no utilizados 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"
}
}
}
Inicio de la compilación
El primer evento de una transmisión BEP, BuildStarted, incluye metadatos que describen el comando antes de que comience un trabajo significativo.
Registros de la herramienta de compilación
Se envía un solo evento BuildToolLogs al final de un comando, incluidos los URI de archivos generados por la herramienta de compilación que pueden ayudar a comprender o depurar el comportamiento de la herramienta de compilación. Es posible que parte de la información se incluya 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"
}
]
}
}
Línea de comandos
La BEP contiene varios eventos CommandLine que contienen representaciones de todos los argumentos de la 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. Estos tres eventos aparecen en la BEP:
"original": Línea de comandos reconstruida a medida que Bazel la recibió del cliente de Bazel, sin opciones de inicio provenientes de archivos .rc."canonical": Es la línea de comandos efectiva con archivos .rc expandida y la política de invocación aplicada."tool": Se propaga a partir de 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 de la BEP. Podría ser un mensaje de búfer de protocolo binarioCommandLinecodificado en base64 que se usa directamente, o una string que se analiza, pero no se interpreta (ya que las opciones de la herramienta pueden ser diferentes de las de Bazel).
Configuración
Se envía un evento Configuration por cada configuration que se use en los objetivos de nivel superior de una compilación. Siempre hay al menos un evento de configuración presente. Los ID de evento TargetConfigured y TargetComplete reutilizan id, que es necesario para desambiguar esos eventos en compilaciones de configuración múltiple.
{
"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"
}
}
}
Conveniencias Simlinks identificadas
Experimental. Si se configuró 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 lugar de trabajo.
Esto permite compilar herramientas que invoquen a Bazel de forma remota y, luego, organizar el lugar 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"
}
]
}
}
Fetch
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 en caché, este no aparece en la transmisión de BEP.
SetDSetOfFiles
Los eventos NamedSetOfFiles informan una estructura que coincide con un depset de archivos generados durante la evaluación de comandos.
Los depsets que se incluyen de forma transitoria se identifican con NamedSetOfFilesId.
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.
Opciones analizadas
Un solo evento OptionsParsed enumera todas las opciones aplicadas al comando, lo que separa las opciones de inicio de las opciones del comando. También incluye la 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",
"--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": {}
}
}
Patrón expandido
Los eventos PatternExpanded indican el conjunto de todos los destinos que coinciden con los patrones
proporcionados en la línea de comandos. Para los comandos exitosos, hay un solo evento presente con todos los patrones de PatternExpandedId y todos los objetivos de los elementos secundarios del evento PatternExpanded. Si el patrón se expande a cualquier test_suite, el conjunto de destinos de prueba incluidos por test_suite. Para cada patrón que no se puede resolver, 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"
}
}
}
Progress
Los eventos de progreso contienen la salida y el error estándar producidos por Bazel durante la ejecución del comando. Estos eventos también se generan automáticamente según sea necesario para anunciar eventos que un anuncio "lógico" superior no anuncia (en particular, NamedSetOfFiles).
Objetivo completado
Para cada combinación de (target, configuration, aspect) que completa la fase de ejecución, se incluye un evento TargetComplete en BEP. El evento contiene
el éxito o fracaso 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"
}
]
}
]
}
}
Configurado en destino
Para cada destino que completa la fase de análisis, se incluye un evento TargetConfigured en BEP. Esta es la fuente autorizada del atributo
“tipo de regla” de un destino. Las configuraciones aplicadas al destino aparecerán en los elementos secundarios anunciados del evento.
Por ejemplo, compilar con las opciones de --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"
}
}
Resumen de objetivos
Para cada par de (target, configuration) que se ejecuta, se incluye un evento TargetSummary
con un resultado agregado exitoso que incluye la ejecución del destino
configurado y todos los aspectos aplicados a ese destino configurado.
TestResult
Si se solicitan pruebas, se envía un evento TestResult por cada intento de prueba,
fragmentado y ejecutado por prueba. Esto permite a los consumidores de BEP identificar con precisión qué acciones de prueba fallaron y también identificar los resultados de pruebas (como registros, archivos test.xml) para cada acción de prueba.
Resumen de pruebas
Si se solicitan pruebas, se envía un evento TestSummary para cada (target,
configuration) de prueba que contiene información necesaria a fin de interpretar los resultados de las pruebas. Se incluye la cantidad de intentos, fragmentos y ejecuciones por prueba para permitir que los consumidores de PIP diferencien los artefactos de estas dimensiones. Los intentos y ejecuciones por prueba se consideran mientras se produce el TestStatus agregado para diferenciar las pruebas FLAKY de las pruebas FAILED.
LíneaUnCommandCommand
A diferencia de CommandLine, este evento lleva las marcas de línea de comandos sin analizar en formato de string que 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.
Configuración de lugar de trabajo
Un solo evento WorkspaceConfig contiene información de configuración relacionada con el
lugar de trabajo, como la raíz de ejecución.
Estado del lugar de trabajo
Un solo evento WorkspaceStatus contiene el resultado del comando de estado del lugar de trabajo.