Encuentra comportamientos no herméticos en las reglas de WORKSPACE

Informar un problema Ver fuente . Por la noche · 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 reales de compilación o prueba no se que se producen en la máquina anfitrión, pero en su lugar se envían a la ejecución remota en un sistema de archivos. Sin embargo, los pasos involucrados en la resolución de las reglas del lugar de trabajo se están llevando a cabo. en la máquina anfitrión. Si tus reglas de Workspace acceden a información sobre el máquina anfitrión para su uso durante la ejecución, es probable que tu compilación se dañe debido a incompatibilidades entre los entornos.

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

Encuentra reglas no herméticas

Las reglas de Workspace permiten que el desarrollador agregue dependencias a en lugares de trabajo externos, pero son lo suficientemente enriquecidos como para permitir que el procesamiento arbitrario en el proceso. Todos los comandos relacionados se ejecutan de forma local y pueden ser posible fuente de no hermeticidad. Por lo general, el comportamiento no hermético es presentada mediante 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 agregando la marca --experimental_workspace_rules_log_file=[PATH] tu comando de Bazel. Aquí, [PATH] es el nombre de archivo que usará el registro crear.

Información que debes tener en cuenta:

  • el registro captura los eventos a medida que se ejecutan. Si algunos pasos son no aparecerán en el registro, así que para obtener un resultado completo, olvidas ejecutar bazel clean --expunge de antemano.

  • A veces, las funciones pueden volver a ejecutarse, en cuyo caso, los 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 lugar de trabajo, haz lo siguiente:

  1. Ejecuta bazel clean --expunge. Este comando limpiará la caché local y en 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 el comando de Bazel y ejecutar la compilación.

    Esto produce 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 usando el siguiente comando. Necesitas el código fuente para poder analizar los registro del espacio de trabajo 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 la salida de Bazel integrada. las reglas de firewall.

    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 verifica si hay operaciones no seguras.

El registro consta de WorkspaceEvent mensajes 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 estas pueden introducir dependencias en el entorno de host.

  • download, download_and_extract: Para garantizar compilaciones herméticas, asegúrate de que que se especificó SHA256

  • file y template: No es hermético en sí, pero puede ser un mecanismo para ingresar dependencias del entorno de host en el repositorio. Asegúrate de entender de dónde provienen las entradas y que esta no dependen del entorno del host.

  • os: Esto no es 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í. Al evaluar si tu uso es hermético, ten en cuenta que esto es que se ejecutan en el host y no en los trabajadores. Obtén información específica del entorno desde el host no suele ser una buena idea para compilaciones remotas.

  • symlink: En general, esto es seguro, pero presta atención a las señales de alerta. Cualquier symlink a fuera del repositorio o una ruta de acceso absoluta podría causar problemas o teletrabajador. Si el symlink se crea según las propiedades de la máquina anfitrión probablemente también sería problemático.

  • which: Verificar los programas instalados en el host suele ser problemático ya que los trabajadores pueden tener parámetros de configuración diferentes.