Tópicos avançados sobre dependências externas

Dependências de shadowing no WORKSPACE

Sempre que possível, tenha uma única política de versão no seu projeto, que é necessária para dependências que você compila e que acabam no seu binário final. Em outros casos, é possível usar dependências de sombra:

myproject/WORKSPACE

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 = "...",
)

B/WORKSPACE

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 os dois em myproject sem conflito, a eles 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"}
)

Você também pode usar esse mecanismo para juntar diamantes. Por exemplo, se A e B tiverem a mesma dependência, mas a chamarem por nomes diferentes, una essas dependências em myproject/WORKSPACE.

Substituir repositórios na linha de comando

Para substituir um repositório declarado por um local na linha de comando, use a flag --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 flag --override_repository=foo=/path/to/local/foo.

Os casos de uso incluem o seguinte:

• Depuração de problemas. Por exemplo, para substituir um repositório http_archive por um diretório local em que você pode fazer mudanças com mais facilidade.
• Disponibilização de pacotes de terceiros. Se você estiver em um ambiente em que não é possível fazer chamadas de rede, substitua as regras de repositório baseadas em rede para apontar para diretórios locais em vez disso.

Como usar proxies

O Bazel coleta endereços de proxy das variáveis de ambiente HTTPS_PROXY e HTTP_PROXY e os usa para baixar arquivos HTTP e HTTPS (se especificado).

Suporte a IPv6

Em máquinas somente IPv6, o Bazel pode fazer o download de dependências sem mudanças. No entanto, em máquinas de pilha dupla IPv4/IPv6, 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 consegue resolver/acessar endereços externos, isso pode causar exceções Network unreachable e falhas de build. Nesses casos, é possível substituir o comportamento do Bazel para preferir o IPv6 usando a propriedade do sistema java.net.preferIPv6Addresses=true. 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 Java que precisam se conectar à Internet (como para testes de integração), use a --jvmopt=-Djava.net.preferIPv6Addresses=true flag da ferramenta. Por exemplo, inclua no seu .bazelrc arquivo:

  build --jvmopt=-Djava.net.preferIPv6Addresses

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

Builds off-line

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

Para builds off-line verdadeiros, em que uma entidade diferente fornece todos os arquivos necessários, o Bazel oferece suporte à opção --distdir. Essa flag instrui o Bazel a procurar primeiro nos diretórios especificados por essa opção quando uma regra de repositório pede ao Bazel 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 base do primeiro URL e usa a cópia local se o hash corresponder.

O próprio Bazel usa essa técnica para inicializar off-line do artefato de distribuição. Para isso, ele coleta todas as dependências externas necessárias em um distdir_tar interno.

O Bazel permite a execução de comandos arbitrários em regras de repositório sem saber se eles fazem chamadas para a rede. Portanto, não é possível impor builds totalmente off-line. Para testar se um build funciona corretamente off-line, bloqueie manualmente a rede (como o Bazel faz no bootstrap test).