Cada tipo de evento BEP tem uma semântica própria, documentada minimamente em build_event_stream.proto. O glossário a seguir descreve cada tipo de evento.
Cancelado
Ao contrário de outros eventos, Aborted
não tem um tipo de ID correspondente porque o evento Aborted
substitui eventos de outros tipos. Esse evento indica que o build foi encerrado antes do tempo e que o ID do evento em que ele aparece não foi produzido normalmente. Aborted
contém uma enumeração e uma descrição legível para explicar
por que o build não foi concluído.
Por exemplo, se um build estiver avaliando uma meta quando o usuário interromper o Bazel, o BEP vai conter um evento como este:
{
"id": {
"targetCompleted": {
"label": "//:foo",
"configuration": {
"id": "544e39a7f0abdb3efdd29d675a48bc6a"
}
}
},
"aborted": {
"reason": "USER_INTERRUPTED"
}
}
ActionExecuted
Fornece detalhes sobre a execução de uma ação específica em um build. Por padrão, esse evento é incluído no BEP apenas para ações com falha, para ajudar a identificar a causa raiz das falhas de build. Os usuários podem definir a flag --build_event_publish_all_actions
para incluir todos os eventos ActionExecuted
.
BuildFinished
Um único evento BuildFinished
é enviado após a conclusão do comando e
inclui o código de saída do comando. Esse evento fornece informações
autorizadas de sucesso/falha.
BuildMetadata
Contém o conteúdo analisado da flag --build_metadata
. Esse evento existe para oferecer suporte à integração do Bazel com outras ferramentas, conectando dados externos (como identificadores).
BuildMetrics
Um único evento BuildMetrics
é enviado no final de cada comando e inclui
contadores/medidores úteis para quantificar o comportamento da ferramenta de build durante o
comando. Essas métricas indicam o trabalho realmente feito e não contam o trabalho em cache
que é reutilizado.
memory_metrics
pode não ser preenchido se não houver coleta de lixo do Java
durante a execução do comando. Os usuários podem definir a opção --memory_profile=/dev/null
, que força o coletor de lixo a ser executado no final do comando para preencher memory_metrics
.
{
"id": {
"buildMetrics": {}
},
"buildMetrics": {
"actionSummary": {
"actionsExecuted": "1"
},
"memoryMetrics": {},
"targetMetrics": {
"targetsLoaded": "9",
"targetsConfigured": "19"
},
"packageMetrics": {
"packagesLoaded": "5"
},
"timingMetrics": {
"cpuTimeInMs": "1590",
"wallTimeInMs": "359"
}
}
}
BuildStarted
O primeiro evento em um stream do BEP, BuildStarted
, inclui metadados que descrevem o
comando antes do início de qualquer trabalho significativo.
BuildToolLogs
Um único evento BuildToolLogs
é enviado ao final de um comando, incluindo URIs de arquivos gerados pela ferramenta de build que podem ajudar a entender ou depurar o comportamento da ferramenta. Algumas informações podem ser incluídas inline.
{
"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
O BEP contém vários eventos CommandLine
com representações de todos os argumentos de linha de comando (incluindo opções e argumentos não interpretados).
Cada evento CommandLine
tem um rótulo no StructuredCommandLineId
que indica qual representação ele transmite. Três desses eventos aparecem no BEP:
"original"
: linha de comando reconstruída conforme o Bazel a recebeu do cliente do Bazel, sem opções de inicialização originadas de arquivos .rc."canonical"
: a linha de comando efetiva com arquivos .rc expandidos e a política de invocação aplicada."tool"
: preenchido com a opção--experimental_tool_command_line
. Isso é útil para transmitir a linha de comando de uma ferramenta que envolve o Bazel pelo BEP. Pode ser uma mensagem de buffer de protocolo binárioCommandLine
codificada em base64 usada diretamente ou uma string analisada, mas não interpretada (já que as opções da ferramenta podem ser diferentes das do Bazel).
Configuração
Um evento Configuration
é enviado para cada configuration
usado nas metas de nível superior em um build. Pelo menos um evento de configuração está sempre presente. O id
é reutilizado pelos IDs de evento TargetConfigured
e
TargetComplete
e é necessário para diferenciar esses eventos em
builds de várias configurações.
{
"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. Se a opção --experimental_convenience_symlinks_bep_event
estiver definida, um único evento ConvenienceSymlinksIdentified
será produzido por
comandos build
para indicar como os symlinks no espaço de trabalho devem ser gerenciados.
Isso permite criar ferramentas que invocam o Bazel remotamente e organizam o espaço de trabalho local como se o Bazel tivesse sido executado localmente.
{
"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"
}
]
}
}
Buscar
Indica que uma operação de busca ocorreu como parte da execução do comando. Ao contrário de outros eventos, se um resultado de busca em cache for reutilizado, esse evento não aparecerá no fluxo do BEP.
NamedSetOfFiles
Os eventos NamedSetOfFiles
informam uma estrutura que corresponde a um
depset
de arquivos produzidos durante a avaliação do comando.
Os conjuntos de dependências transitivamente incluídos são identificados por NamedSetOfFilesId
.
Para mais informações sobre como interpretar eventos NamedSetOfFiles
de um stream, consulte a
página de exemplos do BEP.
OptionsParsed
Um único evento OptionsParsed
lista todas as opções aplicadas ao comando, separando as opções de inicialização das opções de comando. Também inclui o InvocationPolicy, se houver.
{
"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
Os eventos PatternExpanded
indicam o conjunto de todas as segmentações que correspondem aos padrões fornecidos na linha de comando. Para comandos bem-sucedidos, um único evento está presente
com todos os padrões no PatternExpandedId
e todos os destinos nos
filhos do evento PatternExpanded
. Se o padrão se expandir para qualquer test_suite
, o conjunto de destinos de teste será incluído pelo test_suite
. Para cada padrão que não é resolvido, o BEP contém um evento Aborted
adicional com um PatternExpandedId
que identifica o padrão.
{
"id": {
"pattern": {
"pattern":["//base:all"]
}
},
"children": [
{"targetConfigured":{"label":"//base:foo"}},
{"targetConfigured":{"label":"//base:foobar"}}
],
"expanded": {
"testSuiteExpansions": {
"suiteLabel": "//base:suite",
"testLabels": "//base:foo_test"
}
}
}
Progresso
Os eventos de progresso contêm a saída padrão e o erro padrão produzidos pelo Bazel durante a execução do comando. Esses eventos também são gerados automaticamente conforme necessário para anunciar eventos que não foram anunciados por um evento "parent" lógico (em particular, NamedSetOfFiles).
TargetComplete
Para cada combinação de (target, configuration, aspect)
que conclui a fase de execução, um evento TargetComplete
é incluído no BEP. O evento contém o sucesso/falha do destino e os grupos de saída solicitados.
{
"id": {
"targetCompleted": {
"label": "//examples/py:bep",
"configuration": {
"id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
}
}
},
"completed": {
"success": true,
"outputGroup": [
{
"name": "default",
"fileSets": [
{
"id": "0"
}
]
}
]
}
}
TargetConfigured
Para cada destino que conclui a fase de análise, um evento TargetConfigured
é incluído no BEP. Essa é a origem autorizada para o atributo "tipo de regra"
de um destino. As configurações aplicadas ao destino aparecem nos filhos anunciados do evento.
Por exemplo, um build com as opções --experimental_multi_cpu
pode gerar
o seguinte evento TargetConfigured
para um único destino com duas
configurações:
{
"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)
executado, um evento TargetSummary
é incluído com um resultado de sucesso agregado que abrange a execução do
destino configurado e todos os aspectos aplicados a ele.
TestResult
Se o teste for solicitado, um evento TestResult
será enviado para cada tentativa, fragmento e execução por teste. Isso permite que os consumidores do BEP identifiquem precisamente quais ações de teste falharam e os resultados (como registros, arquivos test.xml) de cada ação.
TestSummary
Se o teste for solicitado, um evento TestSummary
será enviado para cada teste (target,
configuration)
, contendo as informações necessárias para interpretar os resultados. O número de tentativas, fragmentos e execuções por teste está incluído para permitir que os consumidores do BEP diferenciem artefatos nessas dimensões. As tentativas e execuções por teste são consideradas ao produzir o TestStatus
agregado para diferenciar os testes FLAKY
dos testes FAILED
.
UnstructuredCommandLine
Ao contrário de CommandLine, esse evento carrega as flags da linha de comando não analisadas em formato de string, conforme encontrado pela ferramenta de build após expandir todos os arquivos .bazelrc
e considerar a flag --config
.
O evento UnstructuredCommandLine
pode ser usado para reproduzir com precisão a execução de um comando específico.
WorkspaceConfig
Um único evento WorkspaceConfig
contém informações de configuração sobre o
espaço de trabalho, como a raiz de execução.
WorkspaceStatus
Um único evento WorkspaceStatus
contém o resultado do comando de status do espaço de trabalho.