O evento de build Protocolo (BEP) permite que programas de terceiros recebam insights sobre uma invocação do Bazel. Para exemplo, você pode usar o BEP para coletar informações para um IDE ou um painel que mostre os resultados do build.
O protocolo é um conjunto de protocolos armazenar mensagens em buffer com algumas semântica definida em cima dele. Ela inclui informações sobre criação e teste do build, o progresso do build, a configuração do build e muito mais. O BEP é devem ser consumidos de forma programática e fazem com que a análise dos dados a saída da linha de comando é uma coisa do passado.
O protocolo de eventos de build representa informações sobre um build como eventos. Um O evento de build é uma mensagem de buffer de protocolo que consiste em um identificador de evento de build, um conjunto de identificadores de eventos filhos e um payload.
Identificador de evento de build: dependendo do tipo de evento de build, ele pode ser: uma opaco string ou estruturados informações revelando mais sobre o evento de build. Um identificador de evento de build é exclusivo um build.
Filhos: um evento de build pode anunciar outros eventos de build, incluindo: os identificadores de eventos de build nos filhos . Por exemplo, o evento de build
PatternExpandedanuncia os destinos que ele expande. como filhos. O protocolo garante que todos os eventos, exceto o primeiro são anunciados por um evento anterior.Payload:o payload contém informações estruturadas sobre um evento de build. codificada como uma mensagem de buffer de protocolo específica do evento. Observe que o payload pode não ser do tipo esperado, mas pode ser uma mensagem
Abortedse o build for cancelado prematuramente.
Criar gráfico de eventos
Todos os eventos de build formam um gráfico acíclico dirigido pelos respectivos pais e filhos relação. Todo evento de compilação, exceto o evento de compilação inicial, tem um ou mais eventos pai. Nem todos os eventos pai de um evento filho devem ser necessariamente postado antes dele. Quando uma versão é concluída (bem-sucedida ou falha) todos os eventos anunciados serão postados. Em caso de falha do Bazel ou transporte de rede, alguns eventos de build anunciados talvez nunca sejam publicados.
A estrutura do gráfico de eventos reflete o ciclo de vida de um comando. A cada BEP gráfico tem a seguinte forma característica:
- O evento raiz é sempre um
BuildStarted. evento. Todos os outros eventos são descendentes. - Os filhos imediatos do evento BuildStarted contêm metadados sobre o kubectl.
- Eventos que contêm dados produzidos pelo comando, como arquivos criados e testados
resultados, aparecem antes da
BuildFinishedevento. - O evento
BuildFinishedpode ser seguido por eventos que contêm informações resumidas sobre o build (por exemplo, métrica ou criação de perfil).
Como consumir o protocolo de evento de build
Consumir em formato binário
Para consumir o BEP em um formato binário:
Faça com que o Bazel serialize as mensagens do buffer de protocolo em um arquivo especificando o opção
--build_event_binary_file=/path/to/file. O arquivo terá mensagens serializadas de buffer de protocolo com cada mensagem delimitada por comprimento. Cada mensagem é prefixada com o comprimento codificado como um número inteiro de comprimento variável. Esse formato pode ser lido usando oparseDelimitedFrom(InputStream).Em seguida, escreva um programa que extraia as informações relevantes das mensagem serializada de buffer de protocolo.
Consumir em formatos de texto ou JSON
As seguintes sinalizações de linha de comando do Bazel vão gerar o BEP em formatos legíveis por humanos, como texto e JSON:
--build_event_text_file
--build_event_json_file
Serviço de evento de build
O evento de build
Serviço
O protocolo é um serviço gRPC genérico para publicar eventos de build. O evento do build
O protocolo de serviço é independente do BEP e trata os eventos do BEP como bytes opacos.
O Bazel acompanha uma implementação de cliente gRPC do protocolo do serviço de evento de build que
publica eventos do Build Event Protocol. É possível especificar o endpoint para enviar
usando a sinalização --bes_backend=HOST:PORT. Se o back-end usar gRPC,
prefixe o endereço com o esquema apropriado: grpc:// para texto simples
gRPC e grpcs:// para gRPC com TLS ativado.
Sinalizações do serviço de evento de build
O Bazel tem várias flags relacionadas ao protocolo do serviço de evento de build, incluindo:
--bes_backend--[no]bes_best_effort--[no]bes_lifecycle_events--bes_results_url--bes_timeout--project_id
Para obter uma descrição de cada uma dessas sinalizações, consulte o Referência da linha de comando.
Autenticação e segurança
A implementação do serviço de evento de build do Bazel também oferece suporte à autenticação e ao TLS. Essas configurações podem ser controladas usando as sinalizações abaixo. Observe que esses também são usadas para a execução remota do Bazel. Isso significa que o Build O serviço de evento e os endpoints de execução remota precisam compartilhar o mesmo e infraestrutura TLS.
--[no]google_default_credentials--google_credentials--google_auth_scopes--tls_certificate--[no]tls_enabled
Para obter uma descrição de cada uma dessas sinalizações, consulte o Referência da linha de comando.
Serviço de evento de build e armazenamento em cache remoto
O BEP normalmente contém muitas referências a arquivos de registro (test.log, test.xml, etc. ) armazenados na máquina em que o Bazel é executado. Um servidor BES remoto normalmente não podem acessar esses arquivos porque eles estão em máquinas diferentes. Uma forma de uma solução alternativa é usar o Bazel com conexões remotos armazenamento em cache. O Bazel faz upload de todos os arquivos de saída para o cache remoto (incluindo arquivos referenciados no BEP) e o servidor BES pode, então, buscar os arquivos referenciados do cache.
Consulte o problema 3689 do GitHub (link em inglês) para mais detalhes.