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
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 antecipadamente e o ID de evento em que ele aparece não foi produzido
normalmente. Aborted contém um tipo enumerado e uma descrição legível para explicar
por que o build não foi concluído.
Por exemplo, se uma compilação estiver avaliando um destino quando o usuário interrompe o Bazel, o BEP 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 Action específica em um build. Por padrão, esse evento é
incluído no BEP apenas para ações com falha, para oferecer suporte à identificação da causa raiz
das falhas de build. Os usuários podem definir a sinalização --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 confiáveis
de sucesso/falha.
BuildMetadata
Contém o conteúdo analisado da sinalização --build_metadata. Esse evento existe
para oferecer suporte à integração do Bazel com outras ferramentas pelo encanamento de 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 realizado e não contabilizam o trabalho reutilizado em cache.
Observe que 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 a execução do coletor
de lixo 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 fluxo do BEP, BuildStarted, inclui metadados que descrevem o comando antes do início de qualquer trabalho significativo.
BuildToolLogs
Um único evento BuildToolLogs é enviado no final de um comando, incluindo URIs
de arquivos gerados pela ferramenta de build que podem ajudar a entender ou depurar
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 todos
os 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 desses eventos aparecem no BEP:
"original": linha de comando reconstruída quando o Bazel a recebeu do cliente do Bazel, sem opções de inicialização provenientes de arquivos .rc."canonical": a linha de comando efetiva com arquivos .rc expandidos e a 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 que é usada diretamente ou uma string que é 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 nos destinos de nível superior em um build. Pelo menos um evento de configuração está sempre presente. O id é reutilizado pelos IDs de eventos 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 pelos comandos build para indicar como gerenciar os links simbólicos no espaço de trabalho.
Isso permite a criação de ferramentas que invocam o Bazel remotamente e organiza o espaço
de trabalho local como se ele 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"
}
]
}
}
Fetch
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 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.
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 de BEP.
OptionsParsed
Um único evento OptionsParsed lista todas as opções aplicadas ao comando,
separando as opções de inicialização e de comando. Ela também inclui a 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 todos os destinos 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 incluídos por test_suite será incluído. Para cada
padrão que não é resolvido, o BEP contém um evento Aborted
extra 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 evento "pai" lógico (em especial NamedSetOfFiles).
TargetComplete
Para cada combinação (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 do destino.
{
"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 fonte autoritativa do atributo "tipo de regra"
de um destino. As configurações aplicadas ao destino aparecem nos
filhos
anunciados do evento.
Por exemplo, a criação com as opções --experimental_multi_cpu pode produzir
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 de (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 de teste. Isso permite que os consumidores do BEP identifiquem com precisão quais
ações de teste falharam nos testes e identifiquem 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 será enviado para cada (target,
configuration) de teste, contendo informações necessárias para interpretar os resultados. O número de tentativas, fragmentos e execuções por teste é 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 testes FLAKY de testes FAILED.
UnstructuredCommandLine
Ao contrário de CommandLine, esse evento carrega as sinalizações de linha de comando
não analisadas em forma de string, conforme encontradas pela ferramenta de build depois de expandir todos os
arquivos .bazelrc e
considerar a sinalização --config.
O evento UnstructuredCommandLine pode ser usado para reproduzir com precisão uma determinada execução de comando.
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 comando
de status do espaço de trabalho.