Encuentra comportamientos no herméticos en las reglas de WORKSPACE

Informar un problema Ver código fuente Nocturno · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

A continuación, se define una máquina host como la máquina en la que se ejecuta Bazel.

Cuando se usa la ejecución remota, los pasos reales de compilación o prueba no se realizan en la máquina host, sino que se envían al sistema de ejecución remota. Sin embargo, los pasos para resolver las reglas del espacio de trabajo se realizan en la máquina host. Si las reglas de tu espacio de trabajo acceden a información sobre la máquina host para usarla durante la ejecución, es probable que tu compilación falle 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 espacio de trabajo y corregirlas. En esta página, se describe cómo encontrar reglas del espacio de trabajo que podrían generar problemas con el registro del espacio de trabajo.

Cómo encontrar reglas no herméticas

Las reglas del espacio de trabajo permiten que el desarrollador agregue dependencias a espacios de trabajo externos, pero son lo suficientemente completas como para permitir que se produzca un procesamiento arbitrario en el proceso. Todos los comandos relacionados se ejecutan de forma local y pueden ser una fuente potencial de no hermeticidad. Por lo general, el comportamiento no hermético se introduce a través de repository_ctx, lo que permite interactuar con la máquina host.

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] a tu comando de Bazel. Aquí, [PATH] es el nombre del 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 se almacenan 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 pueden volver a ejecutarse, en cuyo caso los eventos relacionados aparecerán varias veces en el registro.

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

Para saber qué se ejecutó durante la inicialización del espacio de trabajo, haz lo siguiente:

  1. Ejecuta bazel clean --expunge. Este comando limpiará tu caché local y todos los repositorios almacenados en caché, lo que garantiza que se vuelva a ejecutar toda la inicialización.

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

    Esto genera un archivo .proto binario que enumera los mensajes de tipo WorkspaceEvent.

  3. Descarga el código fuente de Bazel y navega a la carpeta de Bazel con el siguiente comando. Necesitas el código fuente para poder analizar el registro del espacio de trabajo con el analizador de registros del espacio de trabajo.

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

  4. En el repo 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 puede 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 busca operaciones no seguras.

El registro consta de mensajes de WorkspaceEvent que describen ciertas acciones potencialmente no herméticas que se realizan 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. Comprueba si 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 hermético en sí mismo, 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í mismo, sino una forma sencilla de obtener dependencias en el entorno del host. Por lo general, una compilación hermética no llamaría a este método. Cuando evalúes si tu uso es hermético, ten en cuenta que se ejecuta en el host y no en los trabajadores. Por lo general, no es una buena idea obtener detalles específicos del entorno del host para las compilaciones remotas.

  • symlink: Por lo general, esto es seguro, pero busca señales de alerta. Cualquier vínculo simbólico a ubicaciones fuera del repositorio o a una ruta absoluta causaría problemas en el trabajador remoto. Si el vínculo simbólico se crea en función de las propiedades de la máquina host, probablemente también sería problemático.

  • which: Por lo general, verificar los programas instalados en el host es problemático, ya que los trabajadores pueden tener diferentes configuraciones.