Encuentra comportamientos no herméticos en las reglas de WORKSPACE

Informar un problema Ver fuente Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

A continuación, una máquina anfitrión es la máquina en la que se ejecuta Bazel.

Cuando se usa la ejecución remota, los pasos de compilación o prueba reales no ocurren en la máquina host, sino que se envían al sistema de ejecución remota. Sin embargo, los pasos que implican la resolución de reglas de lugar de trabajo se realizan en la máquina host. Si las reglas de tu lugar de trabajo acceden a información sobre la máquina anfitrión para su uso durante la ejecución, es probable que la compilación se dañe debido a incompatibilidades entre los entornos.

Como parte de la adaptación de las reglas de Bazel para la ejecución remota, debes encontrar esas reglas del lugar de trabajo y corregirlas. En esta página, se describe cómo encontrar reglas de Workspace potencialmente problemáticas con el registro de Workspace.

Cómo encontrar reglas no herméticas

Las reglas de espacio de trabajo permiten que el desarrollador agregue dependencias a espacios de trabajo externos, pero son lo suficientemente ricas como para permitir que se realice un procesamiento arbitrario en el proceso. Todos los comandos relacionados ocurren de forma local y pueden ser una posible fuente de no hermeticidad. Por lo general, el comportamiento no hermético se ingresa a través de repository_ctx, que permite la interacción con la máquina anfitrión.

A partir de Bazel 0.18, puedes obtener un registro de algunas acciones potencialmente no herméticas si agregas la marca --experimental_workspace_rules_log_file=[PATH] al comando de Bazel. Aquí, [PATH] es un nombre de archivo con el que se creará el registro.

Información que debes tener en cuenta:

  • el registro captura los eventos a medida que se ejecutan. Si algunos pasos están almacenados en caché, no aparecerán en el registro, por lo que, para obtener un resultado completo, no olvides ejecutar bazel clean --expunge de antemano.

  • A veces, las funciones se pueden volver a ejecutar, en cuyo caso los eventos relacionados aparecerán en el registro varias veces.

  • Actualmente, las reglas de Workspace solo registran eventos de Starlark.

Para encontrar lo que se ejecutó durante la inicialización del lugar de trabajo, haz lo siguiente:

  1. Ejecuta bazel clean --expunge. Este comando limpiará tu caché local y cualquier repositorio almacenado en caché, lo que garantizará que se vuelva a ejecutar toda la inicialización.

  2. Agrega --experimental_workspace_rules_log_file=/tmp/workspacelog al comando de Bazel y ejecuta la compilación.

    Esto produce un archivo proto binario que enumera los mensajes del tipo WorkspaceEvent.

  3. Descarga el código fuente de Bazel y navega a la carpeta de Bazel con el comando que aparece a continuación. Necesitas el código fuente para poder analizar el registro del lugar de trabajo con el analizador de workspacelog.

    git clone https://github.com/bazelbuild/bazel.git
cd bazel

  4. En el repositorio de código fuente de Bazel, convierte todo el registro del espacio de trabajo en texto.

    bazel build src/tools/workspacelog:parser
bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog > /tmp/workspacelog.txt

  5. El resultado puede ser bastante detallado y, además, incluir el resultado de las reglas integradas de Bazel.

    Para excluir reglas específicas del resultado, usa la opción --exclude_rule. Por ejemplo:

    bazel build src/tools/workspacelog:parser
bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog \
    --exclude_rule "//external:local_config_cc" \
    --exclude_rule "//external:dep" > /tmp/workspacelog.txt

  6. Abre /tmp/workspacelog.txt y comprueba si hay operaciones no seguras.

El registro consta de mensajes de WorkspaceEvent que describen ciertas acciones potencialmente no herméticas realizadas en un repository_ctx.

Las acciones que se destacaron como potencialmente no herméticas son las siguientes:

  • execute: Ejecuta un comando arbitrario en el entorno del host. Verifica si estos pueden introducir dependencias en el entorno del host.

  • download, download_and_extract: Para garantizar compilaciones herméticas, asegúrate de que se especifique sha256.

  • file, template: Esto no es no hermético en sí, pero puede ser un mecanismo para introducir dependencias en el entorno del host en el repositorio. Asegúrate de comprender de dónde proviene la entrada y de que no dependa del entorno del host.

  • os: Esto no es no hermético en sí, sino una forma fácil de obtener dependencias en el entorno del host. Una construcción hermética generalmente no se llamaría así. Cuando evalúes si tu uso es hermético, ten en cuenta que esto se ejecuta en el host y no en los trabajadores. Por lo general, obtener información específica del entorno del host no es una buena idea para las compilaciones remotas.

  • symlink: En general, esto es seguro, pero presta atención a las señales de alerta. Cualquier symlink fuera del repositorio o a una ruta absoluta causaría problemas en el trabajador remoto. Si el symlink se crea según las propiedades de la máquina anfitrión, es probable que también haya problemas.

  • which: Comprobar si hay programas instalados en el host suele ser problemático, ya que los trabajadores pueden tener configuraciones diferentes.