Protocolo del evento de compilación

Informar un problema . Ver fuente . . Por la noche · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

El evento de compilación Protocolo (BEP) permite que los programas de terceros obtengan estadísticas de una invocación de Bazel. Para Por ejemplo, puedes usar el BEP para recopilar información de un IDE o un panel que muestre los resultados de compilación.

El protocolo es un conjunto de protocolos almacenar en búfer los mensajes con la semántica definida sobre él. Incluye información sobre compilación y prueba resultados, el progreso de compilación, la configuración de compilación y mucho más. La BEP es destinada a consumirse de forma programática y hace que el análisis de los línea de comandos de salida algo del pasado.

El protocolo de eventos de compilación representa la información sobre una compilación como eventos. R El evento de compilación es un mensaje de búfer de protocolo que consta de un identificador de evento de compilación. un conjunto de identificadores de eventos secundarios y una carga útil.

  • Identificador de eventos de compilación: según el tipo de evento de compilación, puede ser un opaco cadena o estructurados información para revelar más sobre el evento de compilación. Un identificador de evento de compilación es único en una compilación.

  • Secundarios: Un evento de compilación puede anunciar otros eventos de compilación al incluir sus identificadores de eventos de compilación en sus elementos secundarios . Por ejemplo, el evento de compilación PatternExpanded anuncia los objetivos que expande cuando niños. El protocolo garantiza que todos los eventos, excepto el primero, evento anterior, se anuncian en un evento anterior.

  • Carga útil: La carga útil contiene información estructurada sobre un evento de compilación. codificado como un mensaje de búfer de protocolo específico para ese evento. Ten en cuenta que Es posible que la carga útil no sea del tipo esperado, pero podría ser un mensaje Aborted. en caso de que la compilación se anule antes de tiempo.

Crea un gráfico de eventos

Todos los eventos de compilación forman un grafo acíclico dirigido a través de sus elementos superiores y secundarios. relación. Cada evento de compilación, excepto el evento de compilación inicial, tiene uno o o más eventos principales. Ten en cuenta que no todos los eventos principales de un evento secundario deben publicarse antes de la publicación. Cuando se completa una compilación (se realiza de forma correcta o con errores) todos los eventos anunciados estarán publicados. En caso de una falla de Bazel o una transporte de red, es posible que algunos eventos de compilación anunciados nunca se publiquen.

La estructura del gráfico de eventos refleja el ciclo de vida de un comando. Cada BEP gráfico tiene la siguiente forma característica:

  1. El evento raíz siempre es un BuildStarted para cada evento. Todos los demás eventos son sus elementos subordinados.
  2. Los elementos secundarios inmediatos del evento BuildStarted contienen metadatos sobre el kubectl.
  3. Eventos que contienen datos producidos por el comando, como archivos compilados y de prueba resultados, aparecen antes de BuildFinished para cada evento.
  4. Se puede seguir el evento BuildFinished por eventos que contienen información resumida sobre la compilación (por ejemplo, la métrica o la creación de perfiles).

Cómo consumir el protocolo de eventos de compilación

Consumir en formato binario

Para consumir el BEP en un formato binario, haz lo siguiente:

  1. Haz que Bazel serializa los mensajes del búfer de protocolo en un archivo especificando el la opción --build_event_binary_file=/path/to/file. El archivo contendrá mensajes de búfer de protocolo serializados, y cada mensaje está delimitado por la longitud. Cada mensaje tiene un prefijo con su longitud codificada como un número entero de longitud variable. Este formato se puede leer con la biblioteca del búfer de protocolo parseDelimitedFrom(InputStream) .

  2. Luego, escribe un programa que extraiga la información relevante de la mensaje de búfer de protocolo serializado.

Consumir en formatos de texto o JSON

Las siguientes marcas de línea de comandos de Bazel mostrarán el BEP en legibles por humanos, como texto y JSON:

--build_event_text_file
--build_event_json_file

Servicio de evento de compilación

El evento de compilación Servicio El protocolo es un servicio genérico de gRPC para publicar eventos de compilación. El evento de compilación El protocolo de servicio es independiente de BEP y trata los eventos de BEP como bytes opacos. Bazel se envía con una implementación cliente de gRPC del protocolo Build Event Service. publica eventos de Build Event Protocol. Se puede especificar el extremo para enviar hasta usar la marca --bes_backend=HOST:PORT. Si tu backend usa gRPC, debes anteponer el esquema adecuado a la dirección: grpc:// para texto sin formato gRPC y grpcs:// para gRPC con TLS habilitado.

Marcas del servicio de eventos de compilación

Bazel tiene varias marcas relacionadas con el protocolo del servicio de eventos de compilación, incluidas las siguientes:

  • --bes_backend
  • --[no]bes_lifecycle_events
  • --bes_results_url
  • --bes_timeout
  • --bes_instance_name

Para obtener una descripción de cada una de estas marcas, consulta la Referencia de línea de comandos.

Autenticación y seguridad

La implementación del servicio de evento de compilación de Bazel también admite autenticación y TLS. Estos parámetros de configuración se pueden controlar con las siguientes funciones experimentales. Ten en cuenta que estos también se usan para la ejecución remota de Bazel. Esto implica que la compilación Los extremos de ejecución remota y servicio de eventos deben compartir el mismo autenticación y la infraestructura de TLS.

  • --[no]google_default_credentials
  • --google_credentials
  • --google_auth_scopes
  • --tls_certificate
  • --[no]tls_enabled

Para obtener una descripción de cada una de estas marcas, consulta la Referencia de línea de comandos.

Servicio de eventos de compilación y almacenamiento en caché remoto

El BEP suele contener muchas referencias a archivos de registro (test.log, test.xml, etc. ) almacenados en la máquina en la que se ejecuta Bazel. Un servidor de BES remoto normalmente no pueden acceder a estos archivos porque están en máquinas diferentes. Una forma de solucionar este problema es usar Bazel con un control remoto el almacenamiento en caché. Bazel subirá todos los archivos de salida a la caché remota (incluidos los archivos) se hace referencia en el BEP) y el servidor de BES puede recuperar los archivos a los que se hace referencia. de la caché.

Consulta el problema 3689 de GitHub para más detalles.