Hermeticidade

Informar um problema Ver código-fonte

Esta página aborda a hermeticidade, as vantagens de usar builds herméticos e estratégias para identificar o comportamento não hermético nos seus builds.

Visão geral

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

Para isolar a versão, as versões herméticas são insensíveis com as bibliotecas e outros softwares instalados na máquina host local ou remota. Elas dependem de versões específicas de ferramentas de compilação, como compiladores, e dependências, como bibliotecas. Isso torna o processo de compilação autônomo, 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 compilação 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 as versões instaladas de idiomas.
  • Identidade de origem: os sistemas de compilação herméticos tentam garantir a mesma semelhança de 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 compilação 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 sejam alteradas.
  • Execução paralela: para determinada entrada e saída, o sistema de compilação pode criar um gráfico de todas as ações para calcular a execução eficiente e paralela. O sistema de compilação 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 diferentes ferramentas e versões.
  • Reprodutibilidade: as versões herméticas são boas para a solução de problemas porque você sabe as condições exatas que produziram o build.

Como identificar 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 das suas versões existentes com antecedência. Algumas fontes comuns de não hermética em 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, caminhos absolutos e compiladores C++ do sistema para configuração automática de regras C++ nativas)
  • Como gravar na árvore de origem durante a criação. Isso impede que a mesma árvore de origem seja usada para outro destino. A primeira versão grava na árvore de origem, corrigindo a árvore de origem para o destino A. Depois, tentar criar o destino B pode falhar.

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

A partir da 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 o make e receber um build bem-sucedido, a execução do build novamente não recriará nenhum destino. Se você executar cada etapa de versão duas vezes ou em sistemas diferentes, compare um hash do conteúdo do arquivo e receba resultados diferentes. Por isso, o build não pode ser reproduzido.
  • Execute as etapas para depurar ocorrências em cache locais de várias máquinas clientes em potencial para garantir que você detecte qualquer caso de vazamento de ambiente do cliente para as ações.
  • executar uma versão dentro de um contêiner de docker que não contenha nada além da árvore de origem verificada e da lista explícita de ferramentas de host; Falhas no build e mensagens de erro vão capturar dependências implícitas do sistema.
  • Descobrir e corrigir problemas de hermeticidade 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.
  • As regras de espaço de trabalho permitem que os desenvolvedores adicionem dependências a espaços de trabalho externos, mas são ricas o suficiente para permitir o processamento arbitrário no processo. É possível gerar um registro de algumas ações potencialmente não herméticas nas regras do espaço de trabalho do Bazel adicionando a sinalização --experimental_workspace_rules_log_file=PATH ao comando do Bazel.

Hermeticidade com o Bazel

Para saber mais sobre como outros projetos tiveram sucesso usando builds herméticos com o Bazel, veja estas palestras do BazelCon: