Hermeticidade

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

Esta página aborda hermética, os benefícios de usar construções herméticas e estratégias para identificar comportamentos não herméticos nos builds.

Visão geral

Com o mesmo código-fonte de entrada e configuração de produto, uma função hermética o sistema de build sempre retorna a mesma saída, isolando o build das mudanças ao sistema host.

Para isolar o build, os builds herméticos são insensatos às bibliotecas e e outros softwares instalados na máquina host local ou remota. Elas dependem versões específicas de ferramentas de build, como compiladores, e dependências, como bibliotecas. Isso faz com que o processo de build seja autossuficiente, já que não depende serviços externos ao ambiente de build.

Os dois aspectos importantes da hermética são:

  • Isolamento: os sistemas de build herméticos tratam as ferramentas como código-fonte. Eles fazer o download de cópias de ferramentas, gerenciar o armazenamento e usá-las em arquivos gerenciados árvores. Isso cria um isolamento entre a máquina host e o usuário local, incluindo as versões instaladas dos idiomas.
  • Identidade da origem: os sistemas de build herméticos tentam garantir a semelhança da de entrada. Os repositórios de código, como o Git, identificam conjuntos de mutações de código com uma código hash exclusivo. Os sistemas de compilação herméticos usam esse hash para identificar alterações em a entrada do build.

Vantagens

Os principais benefícios das construções herméticas 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 determinadas entradas e saídas, o sistema de build pode construir um gráfico de todas as ações para calcular funções eficientes e paralelas execução. O sistema de build carrega as regras e calcula um gráfico de ações e gera hash para pesquisar no cache.
  • Vários builds: você pode construir vários builds herméticos no mesmo máquina, cada uma criada com diferentes ferramentas e versões.
  • Reprodutibilidade: builds herméticos são bons para solução de problemas, porque você as condições exatas que produziram o build.

Como identificar a não hermética

Se você está se preparando para mudar para o Bazel, a migração fica mais fácil com melhorias dos builds atuais hermeticidade com antecedência. Algumas fontes comuns de não hermética nos builds são:

  • Processamento arbitrário em arquivos .mk
  • Ações ou ferramentas que criam arquivos de forma não determinista, geralmente envolvendo IDs de build ou carimbos de data/hora
  • Binários do sistema que diferem entre hosts (como binários /usr/bin, valores absolutos caminhos, compiladores C++ do sistema para configuração automática de regras C++ nativas).
  • Gravar na árvore de origem durante a compilação. Isso evita que a mesma fonte seja usada para outro destino. O primeiro build grava na origem corrigindo a árvore de origem do destino A. Então, tentar construir o alvo B pode falhar.

Como solucionar problemas de builds não herméticos

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

  • Garanta builds sequenciais nulos: se você executar make e receber um build bem-sucedido, executar o build novamente não deve recriar nenhum destino. Se você executar cada build duas vezes ou em sistemas diferentes, compare um hash do conteúdo do arquivo se o resultado for diferente, a versão não será reproduzível.
  • Execute as etapas para depurar ocorrências em cache local de uma variedade de máquinas clientes em potencial para garantir que você capture qualquer de ambientes do cliente vazando para as ações.
  • Execute uma versão dentro de um contêiner do Docker que não contenha nada além do e uma lista explícita de ferramentas de host. Falhas na construção e as mensagens de erro vão identificar dependências implícitas do sistema.
  • Descobrir e corrigir problemas de hermética usando regras de execução remota.
  • Ative o sandbox restrito no nível por ação, já que as ações em um build podem ter estado e afetar o build ou a saída.
  • Regras do espaço de trabalho que os desenvolvedores adicionem dependências a espaços de trabalho externos, rica o suficiente para permitir que o processamento arbitrário ocorra no processo. Você pode e receber um registro de ações potencialmente não herméticas nas regras de espaço de trabalho do Bazel ao adicionando a flag --experimental_workspace_rules_log_file=PATH a seu comando do Bazel.

Hermeticidade com o Bazel

Para mais informações sobre como outros projetos tiveram sucesso usando o uso de hermética com o Bazel, veja estas conversas da BazelCon: