Acompanhamento de dependências no WORKSPACE
Sempre que possível, tenha uma única política de versão no projeto, que é necessário para as dependências que você compila e acaba no arquivo final binário. 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/ESPAÇO DE TRABALHO
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
têm a mesma dependência, mas chamá-la por nomes diferentes, mesclar 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, faça o seguinte:
use o método
--override_repository
. O uso dessa flag altera o conteúdo dos repositórios externos sem
alterar o código-fonte.
Por exemplo, para substituir @foo
pelo diretório local /path/to/local/foo
,
transmitir 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 no diretório local, onde é 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, substitua as regras de repositório baseadas em rede para apontar para diretórios locais como alternativa.
Como usar proxies
O Bazel coleta endereços de proxy de HTTPS_PROXY
e HTTP_PROXY
.
variáveis de ambiente e as usa para fazer o download dos arquivos HTTP
e HTTPS
(se
especificado).
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,
e dar preferência a IPv4, se ativado. Em algumas situações, por exemplo, quando o IPv4
A rede 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 prefere o IPv6 usando a
Sistema java.net.preferIPv6Addresses=true
propriedade.
Especificamente:
Usar a inicialização
--host_jvm_args=-Djava.net.preferIPv6Addresses=true
padrão, por exemplo, adicionando o linha a seguir no seu arquivo.bazelrc
:startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true
Ao executar destinos de build Java que precisam se conectar à Internet (como quanto aos testes de integração), use o Ferramenta
--jvmopt=-Djava.net.preferIPv6Addresses=true
sinalização. Por exemplo, inclua no seu.bazelrc
arquivo:build --jvmopt=-Djava.net.preferIPv6Addresses
Se você estiver usando o
rules_jvm_external
para a resolução da versão da dependência, adicione também-Djava.net.preferIPv6Addresses=true
para o ambienteCOURSIER_OPTS
para fornecer opções da JVM para Coursier.
Compilações off-line
Às vezes, pode ser necessário executar um build off-line, como ao viajar em 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
o build, use a opção --nofetch
.
Em builds off-line verdadeiros, em que uma entidade diferente fornece todos os arquivos necessários,
O Bazel aceita a opção --distdir
. Essa flag diz ao Bazel para analisar primeiro
aos diretórios especificados por essa opção quando uma regra de repositório solicita que o Bazel
Busque um arquivo com ctx.download
ou
ctx.download_and_extract
De
fornecendo uma soma de hash do arquivo necessário, o Bazel procura um arquivo correspondente ao
basename 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 da distribuição
artefato.
Para isso, ela coleta todas as informações
dependências
em um ambiente
distdir_tar
.
O Bazel permite a execução de comandos arbitrários em regras de repositório sem saber se eles chamarem a rede e, portanto, não puderem aplicar builds totalmente off-line. Para testar se uma versão funciona corretamente off-line, bloquear manualmente a rede (conforme o Bazel faz no bootstrap teste).