Hermeticidade

Informar um problema Ver a fonte Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Esta página aborda a hermeticidade, os benefícios do uso de builds herméticos e estratégias para identificar comportamentos não herméticos nos seus builds.

Visão geral

Quando recebe o mesmo código-fonte de entrada e a mesma configuração de produto, um sistema de build hermético sempre retorna a mesma saída isolando o build de mudanças no sistema host.

Para isolar o build, os builds herméticos não são sensíveis a bibliotecas e outros softwares instalados na máquina host local ou remota. Eles dependem de versões específicas de ferramentas de build, como compiladores, e dependências, como bibliotecas. Isso torna o processo de build independente, já que não depende de serviços externos ao ambiente de build.

Os dois aspectos importantes da hermeticidade são:

  • Isolamento: os sistemas de build herméticos tratam as ferramentas como código-fonte. Eles fazem o download de cópias de ferramentas e gerenciam o armazenamento e o uso em árvores de arquivos gerenciadas. Isso cria um isolamento entre a máquina host e o usuário local, incluindo versões instaladas de idiomas.
  • Identidade da origem: os sistemas de build herméticos tentam garantir a identidade das entradas. Os repositórios de código, como o Git, identificam conjuntos de mutações de código com um código hash exclusivo. Os sistemas de build herméticos usam esse hash para identificar mudanças na entrada do build.

Vantagens

Os principais benefícios dos builds herméticos são:

  • Velocidade: a saída de uma ação pode ser armazenada em cache, e a ação não precisa ser executada novamente, a menos que as entradas mudem.
  • Execução paralela: para entradas e saídas específicas, o sistema de build pode criar um gráfico de todas as ações para calcular uma execução eficiente e paralela. O sistema de build carrega as regras e calcula um gráfico de ação e entradas de hash para pesquisar no cache.
  • Vários builds: é possível criar vários builds herméticos na mesma máquina, cada um usando ferramentas e versões diferentes.
  • Reprodutibilidade: os builds herméticos são bons para a solução de problemas porque você conhece as condições exatas que produziram o build.

Como identificar a não hermeticidade

Se você estiver se preparando para mudar para o Bazel, a migração será mais fácil se você melhorar a hermeticidade dos builds atuais com antecedência. Algumas fontes comuns de não-hermeticidade em builds são:

  • Processamento arbitrário em arquivos .mk
  • Ações ou ferramentas que criam arquivos de forma não determinística, geralmente envolvendo IDs de build ou carimbos de data/hora
  • Binários do sistema que diferem entre hosts (como binários /usr/bin, caminhos absolutos, compiladores C++ do sistema para autoconfigurações de regras C++ nativas)
  • Gravação na árvore de origem durante o build. Isso impede que a mesma árvore de origem seja usada para outro destino. O primeiro build grava na árvore de origem, corrigindo a árvore de origem para o destino A. Então, tentar criar o destino B pode falhar.

Solução de problemas de builds não herméticos

Começando com a execução local, os problemas que afetam as correspondências de cache local revelam ações não herméticas.

  • Verifique builds sequenciais nulos: se você executar make e receber um build bem-sucedido, a execução do build novamente não vai recriar nenhum destino. Se você executar cada etapa de build duas vezes ou em sistemas diferentes, compare um hash do conteúdo do arquivo e receba resultados diferentes. O build não é reproduzível.
  • Execute etapas para depurar acertos de cache local em várias máquinas de cliente em potencial para garantir que você detecte todos os casos de vazamento do ambiente do cliente nas ações.
  • Execute um build em um contêiner do Docker que não contém nada além da árvore de origem extraída e da lista explícita de ferramentas do host. As falhas de build e as mensagens de erro vão detectar dependências implícitas do sistema.
  • Descubra e corrija problemas de hermeticidade usando regras de execução remota.
  • Ative o sandbox no nível de cada ação, já que as ações em um build podem ter estado e afetar o build ou a saída.
  • As regras de espaço de trabalho permitem que os desenvolvedores adicionem dependências a espaços de trabalho externos, mas elas são suficientemente ricas para permitir que o processamento arbitrário aconteça no processo. É possível receber um registro de algumas ações potencialmente não herméticas nas regras do espaço de trabalho do Bazel adicionando a flag --experimental_workspace_rules_log_file=PATH ao comando do Bazel.

Hermeticidade com o Bazel

Para mais informações sobre como outros projetos tiveram sucesso usando builds herméticos com o Bazel, consulte estas palestras do BazelCon: