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, é possível sombrear as dependências:
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 = "...",
)
B/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, fornecendo 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 unir 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
.
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
no diretório local /path/to/local/foo
, transmita a sinalização --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 é possível fazer alterações com mais facilidade. - Fornecedores. Se você estiver em um ambiente em que não é possível fazer chamadas de rede, modifique as regras de repositório baseadas em rede para apontar para diretórios locais.
Como usar proxies
O Bazel pega os endereços de proxy nas variáveis de ambiente HTTPS_PROXY
e HTTP_PROXY
e os usa para fazer o download de 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 que Java, preferindo IPv4 se ativado. Em algumas situações, como quando a rede IPv4
não consegue resolver/alcançar endereços externos, isso pode causar exceções de Network
unreachable
e falhas de build. Nesses casos, é possível substituir
o comportamento do Bazel para dar preferência a IPv6 usando a
propriedade do sistema
java.net.preferIPv6Addresses=true
.
Mais 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 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 da dependência, adicione também-Djava.net.preferIPv6Addresses=true
à variável de ambienteCOURSIER_OPTS
para fornecer opções do JVM para o Coursier.
Compilações off-line
Às vezes, pode ser necessário executar um build off-line, como ao viajar de
um avião. Para casos de uso tão 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 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 analisar primeiro
os diretórios especificados por essa opção quando uma regra de repositório solicitar
que ele busque 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 correspondente 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 o bootstrap off-line do artefato
de distribuição (link em inglês).
Ele faz isso coletando todas as dependências externas necessárias em uma distdir_tar
interna.
Ele permite a execução de comandos arbitrários em regras de repositório sem saber se eles chamam a rede e, portanto, não pode aplicar builds totalmente off-line. Para testar se um build funciona corretamente off-line, bloqueie a rede manualmente, como o Bazel faz no teste bootstrap (link em inglês).