Como encontrar comportamento não hermético nas regras do WORKSPACE

Reportar um problema Ver a fonte Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

A seguir, uma máquina host é aquela em que o Bazel é executado.

Ao usar a execução remota, as etapas reais de build e/ou teste não acontecem na máquina host, mas são enviadas para o sistema de execução remota. No entanto, as etapas envolvidas na resolução das regras do espaço de trabalho estão acontecendo na máquina host. Se as regras do seu espaço de trabalho acessarem informações sobre a máquina host para uso durante a execução, é provável que o build seja interrompido devido a incompatibilidades entre os ambientes.

Como parte da adaptação das regras do Bazel para execução remota, você precisa encontrar e corrigir essas regras de espaço de trabalho. Nesta página, descrevemos como encontrar regras de espaço de trabalho potencialmente problemáticas usando o registro do espaço de trabalho.

Como encontrar regras não herméticas

As regras do espaço de trabalho permitem que o desenvolvedor adicione dependências a espaços de trabalho externos, mas são ricas o suficiente para permitir que o processamento arbitrário aconteça no processo. Todos os comandos relacionados estão acontecendo localmente e podem ser uma fonte potencial de não hermeticidade. Normalmente, o comportamento não hermético é introduzido por repository_ctx, que permite a interação com a máquina host.

A partir do Bazel 0.18, é possível receber um registro de algumas ações potencialmente não herméticas adicionando a flag --experimental_workspace_rules_log_file=[PATH] ao comando do Bazel. Aqui, [PATH] é um nome de arquivo em que o registro será criado.

Observações:

  • o registro captura os eventos conforme eles são executados. Se algumas etapas forem armazenadas em cache, elas não vão aparecer no registro. Para ter um resultado completo, não se esqueça de executar bazel clean --expunge antes.

  • Às vezes, as funções podem ser executadas novamente. Nesse caso, os eventos relacionados aparecem várias vezes no registro.

  • No momento, as regras do Workspace registram apenas eventos do Starlark.

Para saber o que foi executado durante a inicialização do espaço de trabalho:

  1. Execute bazel clean --expunge. Esse comando limpa o cache local e todos os repositórios em cache, garantindo que toda a inicialização seja executada novamente.

  2. Adicione --experimental_workspace_rules_log_file=/tmp/workspacelog ao comando do Bazel e execute a build.

    Isso produz um arquivo proto binário que lista mensagens do tipo WorkspaceEvent

  3. Faça o download do código-fonte do Bazel e vá para a pasta do Bazel usando o comando abaixo. Você precisa do código-fonte para analisar o registro do espaço de trabalho com o analisador de workspacelog.

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

  4. No repositório de código-fonte do Bazel, converta todo o registro do espaço de trabalho em texto.

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

  5. A saída pode ser bastante detalhada e incluir informações das regras integradas do Bazel.

    Para excluir regras específicas da saída, use a opção --exclude_rule. Exemplo:

    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. Abra /tmp/workspacelog.txt e verifique se há operações inseguras.

O registro consiste em mensagens WorkspaceEvent que descrevem determinadas ações potencialmente não herméticas realizadas em um repository_ctx.

As ações destacadas como potencialmente não herméticas são as seguintes:

  • execute: executa um comando arbitrário no ambiente host. Verifique se eles podem introduzir dependências no ambiente do host.

  • download, download_and_extract: para garantir builds herméticos, verifique se o sha256 foi especificado

  • file, template: isso não é não hermético por si só, mas pode ser um mecanismo para introduzir dependências no ambiente host no repositório. Entenda a origem da entrada e verifique se ela não depende do ambiente host.

  • os: isso não é não hermético por si só, mas uma maneira fácil de receber dependências no ambiente host. Um build hermético geralmente não faz essa chamada. Ao avaliar se o uso é hermético, lembre-se de que ele é executado no host e não nos workers. Geralmente, não é uma boa ideia receber especificações do ambiente do host para compilações remotas.

  • symlink: isso geralmente é seguro, mas procure sinais de alerta. Qualquer link simbólico para fora do repositório ou para um caminho absoluto causaria problemas no worker remoto. Se o symlink for criado com base nas propriedades da máquina host, isso também poderá ser problemático.

  • which: verificar os programas instalados no host geralmente é problemático, já que os workers podem ter configurações diferentes.