Regras de repositório HTTP

Informar um problema Ver fonte Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

As seguintes funções podem ser carregadas de @bazel_tools//tools/build_defs/repo:http.bzl.

Regras para fazer o download de arquivos e arquivos compactados por HTTP.

Configuração

Para usar essas regras em uma extensão de módulo, carregue-as no arquivo .bzl e chame-as na função de implementação da extensão. Por exemplo, para usar http_archive:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

def _my_extension_impl(mctx):
  http_archive(name = "foo", urls = [...])

my_extension = module_extension(implementation = _my_extension_impl)

Como alternativa, você pode chamar diretamente essas regras de repositório no arquivo MODULE.bazel com use_repo_rule:

http_archive = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(name = "foo", urls = [...])

http_archive

http_archive(name, add_prefix, auth_patterns, build_file, build_file_content, canonical_id,
             integrity, netrc, patch_args, patch_cmds, patch_cmds_win, patch_tool, patches,
             remote_file_integrity, remote_file_urls, remote_patch_strip, remote_patches,
             repo_mapping, sha256, strip_prefix, type, url, urls, workspace_file,
             workspace_file_content)

Faz o download de um repositório do Bazel como um arquivo compactado, descompacta e disponibiliza os destinos para vinculação.

Ele aceita as seguintes extensões de arquivo: "zip", "jar", "war", "aar", "tar", "tar.gz", "tgz", "tar.xz", "txz", "tar.zst", "tzst", tar.bz2, "ar", ou "deb".

Exemplos: Suponha que o repositório atual contenha o código-fonte de um programa de chat, com raiz no diretório ~/chat-app. Ela precisa depender de uma biblioteca SSL disponível em http://example.com/openssl.zip. O arquivo .zip contém a seguinte estrutura de diretório:

  WORKSPACE
  src/
    openssl.cc
    openssl.h

No repositório local, o usuário cria um arquivo openssl.BUILD que contém a seguinte definição de destino:

  cc_library(
      name = "openssl-lib",
      srcs = ["src/openssl.cc"],
      hdrs = ["src/openssl.h"],
  )

Os destinos no repositório ~/chat-app podem depender desse destino se as linhas a seguir forem adicionadas a ~/chat-app/WORKSPACE:

  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

  http_archive(
      name = "my_ssl",
      url = "http://example.com/openssl.zip",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      build_file = "@//:openssl.BUILD",
  )

Em seguida, os destinos especificariam @my_ssl//:openssl-lib como uma dependência.

Atributos

name Nome: obrigatório

Um nome exclusivo para este repositório.

add_prefix String; opcional

Diretório de destino relativo ao diretório do repositório. O arquivo será descompactado nesse diretório depois de aplicar `strip_prefix` (se houver) aos caminhos de arquivo dentro dele. Por exemplo, o arquivo `foo-1.2.3/src/foo.h` será descompactado em `bar/src/foo.h` se `add_prefix = "bar"` e `strip_prefix = "foo-1.2.3"`.

auth_patterns Dicionário: String -> String; opcional

Um dicionário opcional que mapeia nomes de host para padrões de autorização personalizados. Se o nome do host de um URL estiver presente nesse dicionário, o valor será usado como um padrão ao gerar o cabeçalho de autorização para a solicitação HTTP. Isso permite o uso de esquemas de autorização personalizados usados em muitos provedores comuns de armazenamento em nuvem. No momento, o padrão aceita dois tokens: <login> e <password>, que são substituídos pelo valor equivalente no arquivo netrc para o mesmo nome de host. Depois da formatação, o resultado é definido como o valor do campo Authorization da solicitação HTTP. Exemplo de atributo e netrc para um download HTTP em uma API habilitada para oauth2 usando um token de portador:

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}
netrc:
machine storage.cloudprovider.com
        password RANDOM-TOKEN
A solicitação HTTP final teria o seguinte cabeçalho:
Authorization: Bearer RANDOM-TOKEN

build_file Marcador: opcional

O arquivo a ser usado como o arquivo BUILD para este repositório. Esse atributo é um rótulo absoluto. Use "@//" para o repositório principal. O arquivo não precisa ser chamado BUILD, mas pode ser (algo como BUILD.new-repo-name pode funcionar bem para diferenciá-lo dos arquivos BUILD reais do repositório. É possível especificar build_file ou build_file_content, mas não ambos.

build_file_content String; opcional

O conteúdo do arquivo BUILD para este repositório. É possível especificar build_file ou build_file_content, mas não ambos.

canonical_id String; opcional

Um ID canônico do arquivo baixado. Se especificado e não estiver vazio, o Bazel não vai usar o arquivo do cache, a menos que ele tenha sido adicionado ao cache por uma solicitação com o mesmo ID canônico. Se não for especificado ou estiver vazio, o Bazel usará por padrão os URLs do arquivo como o ID canônico. Isso ajuda a evitar o erro comum de atualizar os URLs sem atualizar também o hash, resultando em builds que são bem-sucedidos localmente, mas falham em máquinas sem o arquivo no cache. Esse comportamento pode ser desativado com --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0.

integrity String; opcional

Checksum esperado no formato de integridade de subrecursos do arquivo baixado. Ele precisa corresponder ao checksum do arquivo baixado. _É um risco de segurança omitir o checksum, já que os arquivos remotos podem mudar. No melhor dos casos, omitir esse campo vai tornar sua build não hermética. É opcional para facilitar o desenvolvimento, mas esse atributo ou "sha256" precisa ser definido antes do envio.

netrc String; opcional

Local do arquivo .netrc a ser usado para autenticação.

patch_args Lista de strings; opcional

Os argumentos fornecidos à ferramenta de patch. O padrão é -p0, mas -p1 geralmente é necessário para patches gerados pelo git. Se vários argumentos -p forem especificados, o último vai entrar em vigor.Se argumentos diferentes de -p forem especificados, o Bazel vai usar a ferramenta de linha de comando patch em vez da implementação de patch nativa do Bazel. Quando o fallback é feito para a ferramenta de linha de comando patch e o atributo patch_tool não é especificado, "patch" é usado. Isso afeta apenas arquivos de patch no atributo "patches".

patch_cmds Lista de strings; opcional

Sequência de comandos Bash a serem aplicados no Linux/macOS depois que os patches forem aplicados.

patch_cmds_win Lista de strings; opcional

Sequência de comandos do PowerShell a serem aplicados no Windows após a aplicação dos patches. Se esse atributo não for definido, patch_cmds será executado no Windows, o que exige a existência do binário Bash.

patch_tool String; opcional

O utilitário patch(1) a ser usado. Se especificado, o Bazel vai usar a ferramenta de patch especificada em vez da implementação de patch nativa do Bazel.

patches Lista de rótulos: opcional

Uma lista de arquivos que serão aplicados como patches após a extração do arquivo. Por padrão, ele usa a implementação de patch nativa do Bazel, que não oferece suporte a correspondência aproximada e patch binário. No entanto, o Bazel volta a usar a ferramenta de linha de comando patch se o atributo "patch_tool" for especificado ou se houver argumentos diferentes de "-p" no atributo "patch_args".

remote_file_integrity Dicionário: String -> String; opcional

Um mapa de caminhos relativos de arquivos (chave) para o valor de integridade (valor). Esses caminhos relativos precisam ser mapeados para os arquivos (chave) no atributo "remote_file_urls".

remote_file_urls Dicionário: string -> lista de strings; opcional

Um mapa de caminhos relativos (chave) para uma lista de URLs (valor) que serão baixados e disponibilizados como arquivos sobrepostos no repositório. Isso é útil quando você quer adicionar arquivos WORKSPACE ou BUILD.bazel em cima de um repositório existente. Os arquivos são baixados antes da aplicação dos patches no atributo "patches", e a lista de URLs precisa ser de possíveis espelhos do mesmo arquivo. Os URLs são testados em ordem até que um deles funcione.

remote_patch_strip Número inteiro; opcional

O número de barras iniciais a serem removidas do nome do arquivo nos patches remotos.

remote_patches Dicionário: String -> String; opcional

Um mapa do URL do arquivo de patch para o valor de integridade dele. Eles são aplicados após a extração do arquivo e antes da aplicação dos arquivos de patch do atributo "patches". Ele usa a implementação de patch nativa do Bazel. Você pode especificar o número de remoção de patch com "remote_patch_strip".

repo_mapping Dicionário: string -> string; obrigatório

Um dicionário do nome do repositório local para o nome do repositório global. Isso permite controles sobre a resolução de dependências do espaço de trabalho para dependências desse repositório.

Por exemplo, uma entrada "@foo": "@bar" declara que, sempre que este repositório depender de "@foo" (como uma dependência de "@foo//some:target"), ele vai resolver essa dependência em "@bar" declarado globalmente ("@bar//some:target").

sha256 String; opcional

O SHA-256 esperado do arquivo baixado. Ele precisa corresponder ao SHA-256 do arquivo baixado. _É um risco de segurança omitir o SHA-256, já que os arquivos remotos podem mudar._ Na melhor das hipóteses, omitir esse campo vai tornar sua build não hermética. É opcional para facilitar o desenvolvimento, mas esse atributo ou "integrity" precisa ser definido antes do envio.

strip_prefix String; opcional

Um prefixo de diretório a ser removido dos arquivos extraídos. Muitos arquivos contêm um diretório de nível superior com todos os arquivos úteis do arquivo. Em vez de precisar especificar esse prefixo várias vezes no `build_file`, esse campo pode ser usado para remover o prefixo de todos os arquivos extraídos. Por exemplo, suponha que você esteja usando `foo-lib-latest.zip`, que contém o diretório `foo-lib-1.2.3/` em que há um arquivo `WORKSPACE` e os diretórios `src/`, `lib/` e `test/` que contêm o código que você quer criar. Especifique `strip_prefix = "foo-lib-1.2.3"` para usar o diretório `foo-lib-1.2.3` como diretório de nível superior. Se houver arquivos fora desse diretório, eles serão descartados e ficarão inacessíveis (por exemplo, um arquivo de licença de nível superior). Isso inclui arquivos/diretórios que começam com o prefixo, mas não estão no diretório (por exemplo, foo-lib-1.2.3.release-notes"). Se o prefixo especificado não corresponder a um diretório no arquivo, o Bazel vai retornar um erro.

type String; opcional

O tipo de arquivo do item baixado. Por padrão, o tipo de arquivo é determinado pela extensão do arquivo do URL. Se o arquivo não tiver uma extensão, especifique explicitamente uma das seguintes opções: "zip", "jar", "war", "aar", "tar", "tar.gz", "tgz", "tar.xz", "txz", "tar.zst", "tzst", "tar.bz2", "ar" ou"deb".

url String; opcional

Um URL para um arquivo que será disponibilizado para o Bazel. Precisa ser um arquivo ou um URL HTTP ou HTTPS. Os redirecionamentos são seguidos. A autenticação não é compatível. Mais flexibilidade pode ser alcançada com o parâmetro "urls", que permite especificar URLs alternativos para buscar.

urls Lista de strings; opcional

Uma lista de URLs para um arquivo que será disponibilizado ao Bazel. Cada entrada precisa ser um arquivo ou um URL http ou https. Os redirecionamentos são seguidos. A autenticação não é compatível. Os URLs são testados em ordem até que um seja bem-sucedido. Por isso, liste os espelhos locais primeiro. Se todos os downloads falharem, a regra vai falhar.

workspace_file Marcador: opcional

O arquivo a ser usado como o arquivo "WORKSPACE" para este repositório. É possível especificar "workspace_file" ou "workspace_file_content", ou nenhum dos dois, mas não ambos.

workspace_file_content String; opcional

O conteúdo do arquivo WORKSPACE para este repositório. É possível especificar "workspace_file" ou "workspace_file_content", ou nenhum dos dois, mas não ambos.

http_file

http_file(name, auth_patterns, canonical_id, downloaded_file_path, executable, integrity, netrc,
          repo_mapping, sha256, url, urls)

Faz o download de um arquivo de um URL e o disponibiliza para uso como um grupo de arquivos.

Exemplos: Suponha que você precise de um pacote Debian para suas regras personalizadas. Esse pacote está disponível em http://example.com/package.deb. Em seguida, adicione ao arquivo WORKSPACE:

  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")

  http_file(
      name = "my_deb",
      url = "http://example.com/package.deb",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  )

Os destinos especificariam @my_deb//file como uma dependência para depender desse arquivo.

Atributos

name Nome: obrigatório

Um nome exclusivo para este repositório.

auth_patterns Dicionário: String -> String; opcional

Um dicionário opcional que mapeia nomes de host para padrões de autorização personalizados. Se o nome do host de um URL estiver presente nesse dicionário, o valor será usado como um padrão ao gerar o cabeçalho de autorização para a solicitação HTTP. Isso permite o uso de esquemas de autorização personalizados usados em muitos provedores comuns de armazenamento em nuvem. No momento, o padrão aceita dois tokens: <login> e <password>, que são substituídos pelo valor equivalente no arquivo netrc para o mesmo nome de host. Depois da formatação, o resultado é definido como o valor do campo Authorization da solicitação HTTP. Exemplo de atributo e netrc para um download HTTP em uma API habilitada para oauth2 usando um token de portador:

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}
netrc:
machine storage.cloudprovider.com
        password RANDOM-TOKEN
A solicitação HTTP final teria o seguinte cabeçalho:
Authorization: Bearer RANDOM-TOKEN

canonical_id String; opcional

Um ID canônico do arquivo baixado. Se especificado e não estiver vazio, o Bazel não vai usar o arquivo do cache, a menos que ele tenha sido adicionado ao cache por uma solicitação com o mesmo ID canônico. Se não for especificado ou estiver vazio, o Bazel usará por padrão os URLs do arquivo como o ID canônico. Isso ajuda a evitar o erro comum de atualizar os URLs sem atualizar também o hash, resultando em builds que são bem-sucedidos localmente, mas falham em máquinas sem o arquivo no cache. Esse comportamento pode ser desativado com --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0.

downloaded_file_path String; opcional

Caminho atribuído ao arquivo baixado

executable Booleano; opcional

Se o arquivo baixado precisa ser executável.

integrity String; opcional

Checksum esperado no formato de integridade de subrecursos do arquivo baixado. Ele precisa corresponder ao checksum do arquivo baixado. _É um risco de segurança omitir o checksum, já que os arquivos remotos podem mudar. No melhor dos casos, omitir esse campo vai tornar sua build não hermética. É opcional para facilitar o desenvolvimento, mas esse atributo ou "sha256" precisa ser definido antes do envio.

netrc String; opcional

Local do arquivo .netrc a ser usado para autenticação.

repo_mapping Dicionário: string -> string; obrigatório

Um dicionário do nome do repositório local para o nome do repositório global. Isso permite controles sobre a resolução de dependências do espaço de trabalho para dependências desse repositório.

Por exemplo, uma entrada "@foo": "@bar" declara que, sempre que este repositório depender de "@foo" (como uma dependência de "@foo//some:target"), ele vai resolver essa dependência em "@bar" declarado globalmente ("@bar//some:target").

sha256 String; opcional

O SHA-256 esperado do arquivo baixado. Ele precisa corresponder ao SHA-256 do arquivo baixado. _É um risco de segurança omitir o SHA-256, já que os arquivos remotos podem mudar._ Na melhor das hipóteses, omitir esse campo vai tornar sua build não hermética. É opcional para facilitar o desenvolvimento, mas precisa ser definido antes do envio.

url String; opcional

Um URL para um arquivo que será disponibilizado para o Bazel. Precisa ser um arquivo ou um URL HTTP ou HTTPS. Os redirecionamentos são seguidos. A autenticação não é compatível. Mais flexibilidade pode ser alcançada com o parâmetro "urls", que permite especificar URLs alternativos para buscar.

urls Lista de strings; opcional

Uma lista de URLs para um arquivo que será disponibilizado ao Bazel. Cada entrada precisa ser um arquivo ou um URL http ou https. Os redirecionamentos são seguidos. A autenticação não é compatível. Os URLs são testados em ordem até que um seja bem-sucedido. Por isso, liste os espelhos locais primeiro. Se todos os downloads falharem, a regra vai falhar.

http_jar

http_jar(name, auth_patterns, canonical_id, downloaded_file_name, integrity, netrc, repo_mapping,
         sha256, url, urls)

Faz o download de um jar de um URL e o disponibiliza como java_import.

Os arquivos baixados precisam ter uma extensão .jar.

Exemplos: Suponha que o repositório atual contenha o código-fonte de um programa de chat, com raiz no diretório ~/chat-app. Ele precisa depender de uma biblioteca SSL disponível em http://example.com/openssl-0.2.jar.

Os destinos no repositório ~/chat-app podem depender desse destino se as seguintes linhas forem adicionadas a ~/chat-app/WORKSPACE:

  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_jar")

  http_jar(
      name = "my_ssl",
      url = "http://example.com/openssl-0.2.jar",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  )

Os destinos especificariam @my_ssl//jar como uma dependência para depender desse jar.

Você também pode referenciar arquivos no sistema atual (localhost) usando "file:///path/to/file" se estiver em sistemas baseados em Unix. Se você estiver no Windows, use "file:///c:/path/to/file". Nos dois exemplos, observe as três barras (/). As duas primeiras pertencem a file://, e a terceira, ao caminho absoluto do arquivo.

Atributos

name Nome: obrigatório

Um nome exclusivo para este repositório.

auth_patterns Dicionário: String -> String; opcional

Um dicionário opcional que mapeia nomes de host para padrões de autorização personalizados. Se o nome do host de um URL estiver presente nesse dicionário, o valor será usado como um padrão ao gerar o cabeçalho de autorização para a solicitação HTTP. Isso permite o uso de esquemas de autorização personalizados usados em muitos provedores comuns de armazenamento em nuvem. No momento, o padrão aceita dois tokens: <login> e <password>, que são substituídos pelo valor equivalente no arquivo netrc para o mesmo nome de host. Depois da formatação, o resultado é definido como o valor do campo Authorization da solicitação HTTP. Exemplo de atributo e netrc para um download HTTP em uma API habilitada para oauth2 usando um token de portador:

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}
netrc:
machine storage.cloudprovider.com
        password RANDOM-TOKEN
A solicitação HTTP final teria o seguinte cabeçalho:
Authorization: Bearer RANDOM-TOKEN

canonical_id String; opcional

Um ID canônico do arquivo baixado. Se especificado e não estiver vazio, o Bazel não vai usar o arquivo do cache, a menos que ele tenha sido adicionado ao cache por uma solicitação com o mesmo ID canônico. Se não for especificado ou estiver vazio, o Bazel usará por padrão os URLs do arquivo como o ID canônico. Isso ajuda a evitar o erro comum de atualizar os URLs sem atualizar também o hash, resultando em builds que são bem-sucedidos localmente, mas falham em máquinas sem o arquivo no cache. Esse comportamento pode ser desativado com --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0.

downloaded_file_name String; opcional

Nome do arquivo atribuído ao jar baixado.

integrity String; opcional

Checksum esperado no formato de integridade de subrecursos do arquivo baixado. Ele precisa corresponder ao checksum do arquivo baixado. _É um risco de segurança omitir o checksum, já que os arquivos remotos podem mudar. No melhor dos casos, omitir esse campo vai tornar sua build não hermética. É opcional para facilitar o desenvolvimento, mas esse atributo ou "sha256" precisa ser definido antes do envio.

netrc String; opcional

Local do arquivo .netrc a ser usado para autenticação.

repo_mapping Dicionário: string -> string; obrigatório

Um dicionário do nome do repositório local para o nome do repositório global. Isso permite controles sobre a resolução de dependências do espaço de trabalho para dependências desse repositório.

Por exemplo, uma entrada "@foo": "@bar" declara que, sempre que este repositório depender de "@foo" (como uma dependência de "@foo//some:target"), ele vai resolver essa dependência em "@bar" declarado globalmente ("@bar//some:target").

sha256 String; opcional

O SHA-256 esperado do arquivo baixado. Ele precisa corresponder ao SHA-256 do arquivo baixado. _É um risco de segurança omitir o SHA-256, já que os arquivos remotos podem mudar._ Na melhor das hipóteses, omitir esse campo vai tornar sua build não hermética. É opcional para facilitar o desenvolvimento, mas esse atributo ou "integrity" precisa ser definido antes do envio.

url String; opcional

Um URL para um arquivo que será disponibilizado para o Bazel. Precisa ser um arquivo ou um URL HTTP ou HTTPS. Os redirecionamentos são seguidos. A autenticação não é compatível. Mais flexibilidade pode ser alcançada com o parâmetro "urls", que permite especificar URLs alternativos para buscar. O URL precisa terminar em ".jar".

urls Lista de strings; opcional

Uma lista de URLs para um arquivo que será disponibilizado ao Bazel. Cada entrada precisa ser um arquivo ou um URL http ou https. Os redirecionamentos são seguidos. A autenticação não é compatível. Os URLs são testados em ordem até que um seja bem-sucedido. Por isso, liste os espelhos locais primeiro. Se todos os downloads falharem, a regra vai falhar. Todos os URLs precisam terminar em ".jar".