Cada tipo de evento BEP tem sua própria semântica, minimamente documentada em build_event_stream.proto. O glossário a seguir descreve cada tipo de evento.
Cancelado
Diferentemente 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
a compilação foi encerrada antecipadamente e o ID de evento em que ele aparece não foi produzido;
normalmente. Aborted contém uma enumeração e uma descrição legível para humanos.
por que o build não foi concluído.
Por exemplo, se uma versão estiver avaliando um destino quando o usuário interrompe o Bazel, O BEP contém um evento como o seguinte:
{
"id": {
"targetCompleted": {
"label": "//:foo",
"configuration": {
"id": "544e39a7f0abdb3efdd29d675a48bc6a"
}
}
},
"aborted": {
"reason": "USER_INTERRUPTED"
}
}
ActionExecuted
Mostra detalhes sobre a execução de um
Action em um build. Por padrão, este evento é
incluída no BEP apenas para ações com falha, para apoiar a identificação da causa raiz
de falhas de build. Os usuários podem definir a sinalização --build_event_publish_all_actions
para incluir todos os eventos de ActionExecuted.
BuildFinished
Um único evento BuildFinished é enviado depois que o comando é concluído e
inclui o código de saída do comando. Esse evento oferece
informações de sucesso/falha.
BuildMetadata
Contém o conteúdo analisado da sinalização --build_metadata. Este evento existe
oferecer suporte à integração do Bazel com outras ferramentas, disponibilizando dados externos (como
identificadores).
BuildMetrics
Um único evento BuildMetrics é enviado ao final de cada comando e inclui
contadores/medidores úteis para quantificar o comportamento da ferramenta de compilação durante o
kubectl. Essas métricas indicam o trabalho realmente realizado e não contabilizam o armazenamento em cache.
trabalho reutilizado.
Observe que memory_metrics pode não ser preenchido se não houver lixo do Java.
coleção durante a execução do comando. Os usuários podem definir
A opção --memory_profile=/dev/null, que força o lixo
que será executado ao 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 BEP, BuildStarted, inclui metadados que descrevem a
antes que qualquer trabalho significativo comece.
BuildToolLogs
Um único evento BuildToolLogs é enviado no final de um comando, incluindo URIs.
de arquivos gerados pela ferramenta de build que podem ajudar na compreensão ou na depuração
o comportamento da ferramenta de build. 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 que contêm representações de todas
argumentos de linha de comando (incluindo opções e argumentos não interpretados).
Cada evento CommandLine tem um rótulo em StructuredCommandLineId que
indica qual representação ele transmite; três eventos assim aparecem no BEP:
"original": linha de comando reconstruída quando o Bazel a recebe do Bazel. sem opções de inicialização provenientes de arquivos .rc."canonical": a linha de comando efetiva com arquivos .rc expandidos e política de invocação aplicada."tool": preenchido a partir da opção--experimental_tool_command_line. Isso é útil para transmitir a linha de comando de uma ferramenta que envolve o Bazel por meio do BEP. Pode ser uma mensagem de buffer de protocolo binárioCommandLinecodificada em base64 usado diretamente, ou uma string que é analisada, mas não interpretada (como as opções da ferramenta podem ser diferentes das do Bazel).
Configuração
Um evento Configuration é enviado para cada configuration
usados nos destinos de nível superior em um build. Pelo menos um evento de configuração é
esteja sempre presente. O id é reutilizado pelo TargetConfigured e
TargetComplete e é necessária para remover a ambiguidade desses eventos da
ou com 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 o --experimental_convenience_symlinks_bep_event
for definida, um único evento ConvenienceSymlinksIdentified será produzido pelo
Comandos build para indicar como os links simbólicos no espaço de trabalho precisam ser gerenciados.
Isso permite criar ferramentas que invocam o Bazel remotamente e organizam a
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 armazenado em cache for reutilizado, esse evento não aparecem no fluxo BEP.
NamedSetOfFiles
NamedSetOfFiles eventos informam uma estrutura que corresponde a
depset de arquivos produzidos durante a avaliação do comando.
As desativações incluídas de modo transitivo são identificadas 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. Ele 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
fornecida na linha de comando. Para comandos bem-sucedidos, um único evento está presente
com todos os padrões em PatternExpandedId e todos os destinos na
filhos do evento PatternExpanded. Se o padrão se expandir
O test_suite define o conjunto de destinos de teste incluídos pelo test_suite. Para cada
que não for resolvido, o BEP conterá um Aborted adicional
com um PatternExpandedId identificando 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 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 "pai" lógico evento (em especificamente, NamedSetOfFiles.)
TargetComplete
Para cada combinação de (target, configuration, aspect) que completa o
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 do destino.
{
"id": {
"targetCompleted": {
"label": "//examples/py:bep",
"configuration": {
"id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
}
}
},
"completed": {
"success": true,
"outputGroup": [
{
"name": "default",
"fileSets": [
{
"id": "0"
}
]
}
]
}
}
TargetConfigured
Para cada objetivo que conclui a fase de análise, um evento TargetConfigured é
incluídos no BEP. Esta é a fonte autorizada para o "tipo de regra" de um destino.
. As configurações aplicadas ao destino aparecem
children do evento.
Por exemplo, criar com as opções --experimental_multi_cpu pode produzir
o seguinte evento TargetConfigured para um único destino com dois
de configuração:
{
"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 TargetSummary
evento seja incluído com um resultado de sucesso agregado que inclua os
a execução do destino e todos os aspectos aplicados a esse destino configurado.
TestResult
Se o teste for solicitado, um evento TestResult será enviado para cada tentativa de teste.
fragmentar e executar por teste. Isso permite que os consumidores do BEP identifiquem com precisão
as ações de teste falharam nos testes e identifique as saídas do teste (como registros,
arquivos test.xml) para cada ação de teste.
TestSummary
Se o teste for solicitado, um evento TestSummary é enviado para cada teste (target,
configuration), contendo as informações necessárias para interpretar o
resultados. O número de tentativas, fragmentos e execuções por teste são incluídos para ativar
os consumidores do BEP para diferenciar artefatos nessas dimensões. As tentativas
e execuções por teste são consideradas ao produzir o TestStatus agregado para
diferenciar testes FLAKY de testes FAILED.
UnstructuredCommandLine
Ao contrário de CommandLine, esse evento carrega a linha de comando não analisada
em formato de string, conforme encontrado pela ferramenta de build depois de expandir todos
Arquivos do .bazelrc e
considerando a flag --config.
O evento UnstructuredCommandLine pode ser usado para reproduzir precisamente uma
com a execução do comando especificado.
WorkspaceConfig
Um único evento WorkspaceConfig contém informações de configuração relacionadas ao
espaço de trabalho, como a raiz de execução.
WorkspaceStatus
Um único evento WorkspaceStatus contém o resultado do status do espaço de trabalho
comando.