Como adaptar regras do Bazel para execução remota

Informar um problema Mostrar fonte Por noite · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

Esta página é destinada a usuários do Bazel que escrevem regras personalizadas de compilação e teste. que querem entender os requisitos das regras do Bazel no contexto de a execução remota.

A execução remota permite que o Bazel execute ações em uma plataforma separada, como em um data center. O Bazel usa uma Protocolo gRPC para a execução remota. Tente a execução remota com bazel-buildfarm um projeto de código aberto que visa fornecer uma execução remota distribuída de plataforma.

Esta página usa a terminologia a seguir ao se referir a diferentes tipos de ambiente ou plataformas:

  • Plataforma host: onde o Bazel é executado.
  • Plataforma de execução: onde as ações do Bazel são executadas.
  • Plataforma segmentada: onde as saídas de build (e algumas ações) são executadas.

Visão geral

Ao configurar uma compilação do Bazel para execução remota, você precisa seguir as diretrizes descritas nesta página para garantir que o build seja executado remotamente sem erros. Isso se deve à natureza da execução remota, ou seja:

  • Ações de build isoladas. As ferramentas de build não retêm estado e dependências não consegue vazar entre eles.

  • Ambientes de execução diversos. A configuração do build local nem sempre é adequado para ambientes de execução remota.

Esta página descreve os problemas que podem surgir na implementação personalizada do Bazel criar e testar regras para execução remota e como evitá-las. Ele abrange os seguintes tópicos:

Como invocar ferramentas de build usando regras de conjunto de ferramentas

Uma regra de conjunto de ferramentas do Bazel é um provedor de configuração que informa a uma regra de build o que ferramentas de build, como compiladores e vinculadores, para usar e como configurá-las usando parâmetros definidos pelo criador da regra. Uma regra de conjunto de ferramentas permite que e regras de teste para invocar ferramentas de build de maneira previsível e pré-configurada que seja compatível com a execução remota. Por exemplo, use uma regra de conjunto de ferramentas em vez de invocar ferramentas de build usando PATH, JAVA_HOME ou outros métodos variáveis que não podem ser definidas como valores equivalentes (ou de forma alguma) no aplicativo ou ambiente de execução.

Atualmente, existem regras de conjunto de ferramentas para regras de build e teste do Bazel para Scala, Rust, e Go, e novas regras de conjunto de ferramentas serão lançadas para outras linguagens e ferramentas, como bash. Se não existir uma regra de conjunto de ferramentas para a ferramenta usada pela regra, considere Como criar uma regra de conjunto de ferramentas.

Como gerenciar dependências implícitas

Se uma ferramenta de build puder acessar dependências em ações de build, essas ações serão falha quando executada remotamente porque cada ação de compilação remota é executada separadamente dos outros. Algumas ferramentas de build retêm o estado em ações e acessar dependências que não foram explicitamente incluídas na ferramenta que fará com que as ações de compilação executadas remotamente falhem.

Por exemplo, quando o Bazel instrui um compilador com estado a criar foo localmente: o compilador mantém referências às saídas de compilação de foo. Quando o Bazel instrui o compilador a criar bar, que depende de foo, sem afirmando explicitamente que a dependência no arquivo BUILD para inclusão no do compilador, a ação é executada com sucesso, desde que a mesma do compilador é executada para as duas ações (como é comum para execução local). No entanto, como em um cenário de execução remota, cada ação de compilação executa um instância separada do compilador, estado do compilador e dependência implícita de bar na foo será perdido e a compilação falhará.

Para ajudar a detectar e eliminar esses problemas de dependência, o Bazel 0.14.1 oferece a sandbox local do Docker, que tem as mesmas restrições para dependências que a execução. Use o sandbox para preparar seu build para execução remota identificar e resolver erros de build relacionados a dependências. Consulte Como solucionar problemas de execução remota do Bazel com o sandbox do Docker para mais informações.

Como gerenciar binários dependentes da plataforma

Normalmente, um binário criado na plataforma host não pode ser executado com segurança em uma plataforma de execução remota arbitrária devido a dependências potencialmente incompatíveis. Por exemplo, o binário SingleJar fornecido com o Bazel tem como alvo a plataforma do host. No entanto, para execução remota, o SingleJar precisa ser compilado como parte do processo. de compilar o código para que ele seja direcionado à plataforma de execução remota. Consulte a lógica de seleção de destino).

Não envie os binários das ferramentas de build exigidas pelo build com seu código-fonte a menos que você tenha certeza de que elas serão executadas com segurança na plataforma de execução. Em vez disso, uma das seguintes opções:

  • Enviar ou fazer referência externa ao código-fonte da ferramenta para que ela possa ser criada para a plataforma de execução remota.

  • Pré-instale a ferramenta no ambiente de execução remota (por exemplo, um contêiner do conjunto de ferramentas) se ele for estável o suficiente e usar regras de conjunto de ferramentas para executá-lo no seu build.

Como gerenciar regras do espaço de trabalho de estilo de configuração

As regras WORKSPACE do Bazel podem ser usadas para sondar a plataforma do host em busca de ferramentas. e bibliotecas exigidas pelo build, que, para builds locais, também são o código plataforma de execução. Se o build depender explicitamente de ferramentas de compilação locais e artefatos, ele falhará durante a execução remota se a plataforma de execução remota não é idêntica à plataforma de hospedagem.

As seguintes ações realizadas por regras WORKSPACE não são compatíveis com execução remota:

  • Criação de binários Como executar ações de compilação em regras WORKSPACE resulta em binários incompatíveis com a plataforma de execução remota se for diferente da plataforma de hospedagem.

  • Instalando pacotes pip. pip pacotes instalados usando WORKSPACE exigem que as dependências sejam pré-instaladas na plataforma host. Esses pacotes, criados especificamente para a plataforma de hospedagem, serão incompatível com a plataforma de execução remota se for diferente do host de plataforma.

  • Links simbólicos para ferramentas ou artefatos locais. Links simbólicos para ferramentas ou bibliotecas instalado na plataforma de host criada pelas regras WORKSPACE fará com que o na plataforma de execução remota, já que o Bazel não consegue localizá-los. Em vez disso, crie links simbólicos usando ações de compilação padrão para que as ferramentas e bibliotecas com link simbólico podem ser acessadas no runfiles do Bazel. árvore. Não usar o repository_ctx.symlink para criar links simbólicos de arquivos de destino fora do diretório do repositório externo.

  • Como mudar a plataforma de host. Evite criar arquivos fora do Bazel runfiles, criando variáveis de ambiente e ações semelhantes, conforme podem se comportar de maneira inesperada na plataforma de execução remota.

Para encontrar possíveis comportamentos não herméticos, use o registro de regras do Workspace.

Se uma dependência externa executa operações específicas dependentes do host plataforma, divida essas operações entre WORKSPACE e o build da seguinte forma:

  • Inspeção de plataforma e enumeração de dependências. Essas operações são seguros para execução local usando regras WORKSPACE, que verificam quais bibliotecas estão instaladas, baixa os pacotes que devem ser compilados e os artefatos necessários para compilação. Para execução remota, essas regras precisam oferecer suporte ao uso de artefatos pré-verificados para fornecer as informações que normalmente são obtidas durante a inspeção da plataforma host. Pré-marcado os artefatos permitem que o Bazel descreva dependências como se fossem locais. Usar instruções condicionais ou a sinalização --override_repository para isso.

  • Gerar ou compilar artefatos específicos do destino e mutação da plataforma. Essas operações precisam ser executadas por regras de build regulares. Ações que produzir artefatos específicos do destino para dependências externas precisa executar durante o build.

Para gerar artefatos pré-verificados com mais facilidade para execução remota, use Regras WORKSPACE para emitir arquivos gerados. É possível executá-las em cada novo ambiente de execução, como dentro de cada contêiner de conjunto de ferramentas, e verifique os saídas da execução remota são criadas no seu repositório de origem para referência.

Por exemplo, para as regras do TensorFlow para cuda e python, as regras WORKSPACE produzem os seguintes BUILD files. Para execução local, são usados os arquivos produzidos pela verificação do ambiente do host. Para execução remota, uma instrução condicional em uma variável de ambiente, permite que a regra use arquivos verificados no repositório.

Os arquivos BUILD declaram genrules que pode ser executado local e remotamente e que realiza o processamento feito anteriormente pelo repository_ctx.symlink, conforme mostrado aqui.