Detecta comportamientos no herméticos en las reglas de WORKSPACE

Informa un problema Ver código fuente

En la siguiente tabla, 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 de prueba reales no ocurren en la máquina host, sino que se envían al sistema de ejecución remota. Sin embargo, los pasos involucrados en la resolución de las reglas de lugar de trabajo ocurren en la máquina anfitrión. Si las reglas de tu lugar de trabajo acceden a la información sobre la máquina anfitrión para su uso 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 lugar de trabajo y corregirlas. En esta página, se describe cómo encontrar reglas de lugar de trabajo potencialmente problemáticas mediante el registro del lugar de trabajo.

Busca reglas no herméticas

Las reglas de lugares de trabajo permiten que el desarrollador agregue dependencias a los lugares de trabajo externos, pero son lo suficientemente enriquecidos para permitir que se lleve a cabo el procesamiento arbitrario en el proceso. Todos los comandos relacionados ocurren de forma local y pueden ser una posible fuente de no hermetismo. 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] a tu comando de Bazel. Aquí, [PATH] es un nombre de archivo en el que se creará el registro.

Información que deben tener en cuenta:

  • el registro captura los eventos a medida que se ejecutan. Si se almacenan en caché algunos pasos, no se mostrará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 espacio de trabajo, haz lo siguiente:

  1. Ejecuta bazel clean --expunge. Este comando limpiará la caché local y los repositorios almacenados en caché, lo que garantiza que se vuelvan a ejecutar todas las inicializaciones.

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

    Esto produce un archivo binario proto 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 lugar de trabajo con el analizador de registros de lugar de trabajo.

    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 también incluir los resultados 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 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 de host. Verifica si estas pueden introducir dependencias en el entorno host.

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

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

  • os: Esto no es hermético en sí, sino una manera fácil de obtener dependencias en el entorno host. Una compilación hermética no suele llamar esto. Cuando evalúes si el uso es hermético, ten en cuenta que esto se ejecuta en el host y no en los trabajadores. Obtener detalles específicos del entorno del host no suele ser una buena idea para las compilaciones remotas.

  • symlink: Por lo general, es seguro, pero busca indicadores de advertencia. Cualquier symlink para fuera del repositorio o una ruta de acceso absoluta causaría problemas en el trabajador remoto. Si el symlink se crea en función de las propiedades de la máquina host, probablemente también sea un problema.

  • which: Por lo general, la verificación de programas instalados en el host es problemática, ya que los trabajadores pueden tener diferentes configuraciones.