Tópicos avançados sobre dependências externas

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

Acompanhamento de dependências no WORKSPACE

Observação: esta seção se aplica ao espaço de trabalho do Google Cloud. Para Bzlmod, use uma versão de múltiplas substituir.

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.

.

Observação: com o Bzlmod, não se esqueça de usar o repositório canônico nomes aqui. Como alternativa, use o método --override_module para substituir um módulo por um diretório local, semelhante à Diretiva local_path_override em MODULE.bazel.

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 ambiente COURSIER_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).