Regras de repositório

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

Nesta página, você vai aprender a criar regras de repositório e conferir exemplos mais detalhes.

Um repositório externo é uma regra que pode ser usada apenas no arquivo WORKSPACE e permite a operação não hermética na fase de carregamento do Bazel. Cada regra de repositório externo cria o próprio espaço de trabalho, com os próprios arquivos e artefatos BUILD. Eles podem ser usados com dependências (como bibliotecas empacotadas Maven), mas também para gerar arquivos BUILD específico para o host em que o Bazel está sendo executado.

Criação de regra de repositório

Em um arquivo .bzl, use o função repository_rule para criar um novo regra de repositório e armazená-la em uma variável global.

Uma regra de repositório personalizada pode ser usada da mesma forma que uma regra de repositório nativa. Ela tem um atributo name obrigatório e todos os destinos presentes nos arquivos de build pode ser chamado de @<name>//package:target, em que <name> é o valor do name.

A regra é carregada quando você a cria explicitamente ou se for uma dependência de o build. Nesse caso, o Bazel executa a função implementation. Isso descreve como criar o repositório, o conteúdo dele e os arquivos BUILD.

Atributos

Um atributo é um argumento de regra, como url ou sha256. Você deve listar os atributos e os tipos deles ao definir uma regra de repositório.

local_repository = repository_rule(
    implementation=_impl,
    local=True,
    attrs={"path": attr.string(mandatory=True)})

Para acessar um atributo, use repository_ctx.attr.<attribute_name>.

Todos os repository_rules têm atributos definidos implicitamente, assim como o build regras). Os dois atributos implícitos são name (assim como as regras de build) e repo_mapping. O nome de uma regra de repositório pode ser acessado com repository_ctx.name: O significado de repo_mapping é o mesmo que para o regras de repositório nativo local_repository e new_local_repository

Se um nome de atributo começar com _, ele será particular e não poderá ser definido pelos usuários.

Função de implementação

Toda regra de repositório requer uma função implementation. Ele contém lógica real da regra e é executada estritamente na fase de carregamento.

A função tem exatamente um parâmetro de entrada, repository_ctx. A função retorna None para indicar que a regra pode ser reproduzida, considerando o parâmetros especificados ou um dict com um conjunto de parâmetros para essa regra que transformaria essa regra em uma regra reproduzível que gera o mesmo repositório. Para exemplo, para uma regra que rastreia um repositório Git, o que significaria retornar um identificador de commit específico em vez de uma ramificação flutuante especificado.

O parâmetro de entrada repository_ctx pode ser usado para acessar valores de atributos e funções não herméticas (encontrar um binário, executar um binário, criar um arquivo no repositório ou fazer o download de um arquivo da Internet). Acesse a biblioteca para mais informações contexto. Exemplo:

def _impl(repository_ctx):
  repository_ctx.symlink(repository_ctx.attr.path, "")

local_repository = repository_rule(
    implementation=_impl,
    ...)

Quando a função de implementação é executada?

Se o repositório for declarado como local, mude uma dependência. no gráfico de dependência (incluindo o próprio arquivo WORKSPACE) causar a execução da função de implementação.

A função de implementação pode ser reiniciada se uma dependência está ausente. Início da função de implementação serão executadas novamente depois que a dependência for resolvida. Para evitar reinicializações desnecessárias (que são caras, pois o acesso à rede pode repetidos), argumentos de rótulo são pré-buscados, contanto que todos de rótulo podem ser resolvidos em um arquivo atual. A resolução Um caminho de uma string ou um rótulo que foi criado somente durante a execução da função ainda pode causar uma reinicialização.

Por fim, para repositórios que não são local, apenas uma mudança no seguinte dependências podem causar uma reinicialização:

  • Arquivos .bzl necessários para definir a regra de repositório.
  • Declaração da regra de repositório no arquivo WORKSPACE.
  • Valor de qualquer variável de ambiente declarada com o environ do elemento repository_rule função. O valor dessas variáveis de ambiente pode ser aplicado na linha de comando com o --action_env (mas vai invalidar todas as ações da compilação).
  • Conteúdo de qualquer arquivo usado e referido por um marcador (por exemplo, //mypkg:label.txt, e não mypkg/label.txt).

Como forçar uma nova busca de repositórios externos

Às vezes, um repositório externo pode ficar desatualizado sem qualquer mudança ou dependências. Por exemplo, um repositório que busca origens pode seguem uma ramificação específica de um repositório de terceiros, e novas confirmações são disponíveis na ramificação. Nesse caso, você pode pedir ao Bazel para refazer todas as repositórios externos incondicionalmente, chamando bazel sync.

Além disso, algumas regras inspecionam a máquina local e podem se tornar desatualizados se a máquina local foi atualizada. Aqui você pode pedir ao Bazel para apenas rebuscar os repositórios externos em que o repository_rule definição tiver o atributo configure definido, use bazel sync --configure.

Exemplos

  • Conjunto de ferramentas configurado automaticamente para C++: ele usa uma regra de repositório para criar automaticamente arquivos de configuração C++ para Bazel procurando pelo compilador C++ local, o e as sinalizações compatíveis com o compilador C++.

  • Repositórios Go usa vários repository_rule para definir a lista de dependências; necessárias para usar as regras do Go.

  • rules_jvm_external cria Um repositório externo chamado @maven por padrão que gera destinos de build para cada artefato Maven na árvore de dependências transitiva.