Tópicos avançados sobre dependências externas

Informar um problema Acessar a origem

Acompanhamento de dependências no WORKSPACE

Sempre que possível, tenha uma única política de versão no projeto, que é necessária para dependências que você compila e acaba no binário final. Para outros casos, você pode sombrear as dependências:

meu projeto/espaço de trabalho

workspace(name = "myproject")

local_repository(
    name = "A",
    path = "../A",
)
local_repository(
    name = "B",
    path = "../B",
)

A/WORKSPACE

workspace(name = "A")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "...",
)

ESPAÇO DE TRABALHO 

workspace(name = "B")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)

As dependências A e B dependem de versões diferentes de testrunner. Inclua ambos em myproject sem conflito, atribuindo nomes distintos em myproject/WORKSPACE:

workspace(name = "myproject")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner-v1",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "..."
)
http_archive(
    name = "testrunner-v2",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)
local_repository(
    name = "A",
    path = "../A",
    repo_mapping = {"@testrunner" : "@testrunner-v1"}
)
local_repository(
    name = "B",
    path = "../B",
    repo_mapping = {"@testrunner" : "@testrunner-v2"}
)

Esse mecanismo também pode ser usado para unir diamantes. Por exemplo, se A e B tiverem a mesma dependência, mas forem chamadas com nomes diferentes, mescle essas dependências em myproject/WORKSPACE.

Como substituir repositórios pela linha de comando

Para substituir um repositório declarado por um repositório local na linha de comando, use a sinalização --override_repository. O uso dessa flag muda o conteúdo de repositórios externos sem alterar o código-fonte.

Por exemplo, para substituir @foo pelo diretório local /path/to/local/foo, transmita a sinalização --override_repository=foo=/path/to/local/foo.

Os casos de uso incluem:

  • Problemas de depuração. Por exemplo, para substituir um repositório http_archive por um diretório local em que seja possível fazer alterações com mais facilidade.
  • Fornecimento. Se você estiver em um ambiente em que não é possível fazer chamadas de rede, substitua as regras do repositório baseado em rede para apontar para diretórios locais.

Como usar proxies

O Bazel coleta endereços de proxy das variáveis de ambiente HTTPS_PROXY e HTTP_PROXY e os usa para fazer o download dos arquivos HTTP e HTTPS (se especificados).

Suporte para IPv6

Em máquinas somente IPv6, o Bazel pode fazer o download de dependências sem alterações. No entanto, em máquinas IPv4/IPv6 de pilha dupla, o Bazel segue a mesma convenção do Java, preferindo IPv4 se ativado. Em algumas situações, por exemplo, quando a rede IPv4 não pode resolver/alcançar endereços externos, isso pode causar exceções Network unreachable e falhas de criação. Nesses casos, é possível substituir o comportamento do Bazel para preferir o IPv6 usando a propriedade do sistema java.net.preferIPv6Addresses=true (link em inglês). Especificamente:

  • Use a opção de inicialização --host_jvm_args=-Djava.net.preferIPv6Addresses=true, por exemplo, adicionando a seguinte linha ao arquivo .bazelrc:

    startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true

  • Ao executar destinos de build do Java que precisam se conectar à Internet (como para testes de integração), use a sinalização de ferramenta --jvmopt=-Djava.net.preferIPv6Addresses=true. Por exemplo, inclua no seu arquivo .bazelrc:

    build --jvmopt=-Djava.net.preferIPv6Addresses

  • Se você estiver usando rules_jvm_external para a resolução da versão de dependência, adicione também -Djava.net.preferIPv6Addresses=true à variável de ambiente COURSIER_OPTS para fornecer opções da JVM para Coursier.

Builds off-line

Às vezes, você pode querer executar um build off-line, como ao viajar em um avião. Para casos de uso simples, faça a pré-busca dos repositórios necessários com bazel fetch ou bazel sync. Para desativar a busca de mais repositórios durante a criação, use a opção --nofetch.

Para builds off-line reais, em que uma entidade diferente fornece todos os arquivos necessários, o Bazel oferece suporte à opção --distdir. Essa sinalização instrui o Bazel a procurar primeiro os diretórios especificados por essa opção quando uma regra de repositório pede a ele para buscar um arquivo com ctx.download ou ctx.download_and_extract. Ao fornecer uma soma de hash do arquivo necessário, o Bazel procura um arquivo que corresponda ao nome de base do primeiro URL e usa a cópia local se o hash corresponder.

O próprio Bazel usa essa técnica para fazer a inicialização off-line do artefato de distribuição. Isso é feito coletando todas as dependências externas necessárias em um distdir_tar interno.

Ele permite a execução de comandos arbitrários nas regras do repositório sem saber se eles chamam a rede. Portanto, ele não pode aplicar builds totalmente off-line. Para testar se um build funciona corretamente off-line, bloqueie manualmente a rede, como o Bazel faz no teste de bootstrap (link em inglês).