Para conferir a documentação da versão estável, use o menu suspenso "Documentos com controle de versão". A visualização padrão reflete a versão mais recente em HEAD.

Esta página foi traduzida pela API Cloud Translation.

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

Informar um problema Acessar a origem

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

Com a execução remota, as etapas reais de compilação e/ou teste não ocorrem 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 espaço de trabalho acessarem informações sobre a máquina host para uso durante a execução, sua criação provavelmente será interrompida devido a incompatibilidades entre os ambientes.

Como parte da adaptação de 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 problemas 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 suficientes para permitir que o processamento arbitrário ocorra no processo. Todos os comandos relacionados ocorrem localmente e podem ser uma potencial fonte de não hermética. 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 ter um registro de algumas ações potencialmente não herméticas adicionando a sinalização --experimental_workspace_rules_log_file=[PATH] ao seu comando do Bazel. Aqui, [PATH] é o nome do arquivo em que o registro será criado.

Observações:

o registro captura os eventos à medida que eles são executados. Se algumas etapas estiverem armazenadas em cache, elas não serão exibidas no registro. Portanto, para ter um resultado completo, não se esqueça de executar bazel clean --expunge antecipadamente.
Às vezes, as funções podem ser executadas novamente. Nesse caso, os eventos relacionados aparecerão no registro várias vezes.
No momento, as regras do Workspace só registram eventos do Starlark.

Observação: essas regras específicas não causam problemas de hermiticidade, desde que um hash seja especificado.

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

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.
Adicione --experimental_workspace_rules_log_file=/tmp/workspacelog ao comando do Bazel e execute o build.

Isso produz um arquivo .proto binário listando mensagens do tipo WorkspaceEvent.
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
```

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

A saída pode ser bastante detalhada e incluir saídas de 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

Abra /tmp/workspacelog.txt e verifique se há operações não seguras.

O registro consiste em mensagens WorkspaceEvent que descrevem determinadas ações potencialmente não herméticas realizadas em um 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 isso pode introduzir alguma dependência no ambiente do host.
download, download_and_extract: para garantir builds herméticos, confira se sha256 está especificado.
file, template: não é hermético por si só, mas pode ser um mecanismo para introduzir dependências no ambiente do host no repositório. Você precisa entender de onde vem a entrada e que ela não depende do ambiente do host.
os: não é hermético por si só, mas é uma maneira fácil de conseguir dependências no ambiente do host. Uma compilação hermética geralmente não chamaria isso. Ao avaliar se o uso é hermético, lembre-se de que a execução é feita no host, e não nos workers. Geralmente, receber especificações do ambiente do host não é uma boa ideia para builds remotos.
symlink: normalmente é seguro, mas procure sinais de alerta. Todos os links simbólicos para fora do repositório ou para um caminho absoluto causariam problemas no trabalho remoto. Se o link simbólico for criado com base nas propriedades da máquina host, ele provavelmente também será problemático.
which: a verificação de programas instalados no host geralmente é problemática, já que os workers podem ter configurações diferentes.