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

Relatar um problema Conferir código-fonte Por noite · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

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

Ao usar a execução remota, as etapas reais de compilação e/ou teste não são na máquina host, mas são enviados para a execução remota sistema. No entanto, as etapas para resolver as regras do espaço de trabalho são feitas na máquina host. Se as regras do espaço de trabalho acessarem informações sobre máquina host para uso durante a execução, é provável que seu build falhe devido a incompatibilidades entre os ambientes.

Como parte da adaptação de regras do Bazel para controle remoto execução, você precisa encontrar essas regras de espaço de trabalho e corrigi-los. Nesta página, descrevemos como encontrar um espaço de trabalho potencialmente problemático 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 externos, mas eles são ricos o suficiente para permitir o processamento arbitrário para acontecer no processo. Todos os comandos relacionados acontecem localmente e podem ser fonte potencial de não hermética. Normalmente, o comportamento não hermético é introduzido pelo repository_ctx, que permite a interação com a máquina host.

A partir do Bazel 0.18, é possível gerar um registro de algumas instâncias adicionando a flag --experimental_workspace_rules_log_file=[PATH] seu comando do Bazel. Aqui, [PATH] é um nome de arquivo em que o registro será criados.

Observações:

  • o registro captura os eventos à medida que são executados. Se algumas etapas forem armazenados em cache, elas não aparecerão no registro. Portanto, para obter um resultado completo, não se esqueça de executar o bazel clean --expunge com antecedência.

  • Às vezes, as funções podem ser executadas novamente; nesse caso, as funções eventos aparecerão no registro várias vezes.

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

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

  1. Execute bazel clean --expunge. Esse comando limpará seu 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 à sua o comando do Bazel e execute o 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 poder analisar do espaço de trabalho com o analisador do 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 uma saída do Bazel integrado regras de firewall.

    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 não seguras.

O registro consiste em WorkspaceEvent mensagens descrevendo certas ações potencialmente não herméticas realizadas em uma repository_ctx.

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

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

  • download, download_and_extract: para garantir builds herméticos, verifique se para que sha256 seja especificado

  • file, template: não é não hermético por si só, mas pode ser um mecanismo para introduzir dependências no ambiente do host no repositório. Certifique-se de que você entende de onde vem a entrada e que ela não dependem do ambiente do host.

  • os: não é não hermético por si só, mas uma maneira fácil de conseguir dependências. no ambiente do host. Uma construção hermética geralmente não chama isso. Ao avaliar se o uso é hermético, tenha em mente que isso é em execução no host e não nos workers. Como ver detalhes do ambiente do host geralmente não é uma boa ideia para compilações remotas.

  • symlink: normalmente é seguro, mas procure sinais de alerta. Todos os links simbólicos para fora do repositório ou para um caminho absoluto causaria problemas no funcionário remoto. Se o link simbólico for criado com base nas propriedades da máquina host provavelmente também seria problemático.

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