O registro e a CFP da BazelCon 2024 já estão abertos.
Para a documentação da versão estável, use o menu suspenso "Documentos com controle de versão". A visualização padrão reflete a versão mais recente em HEAD.

Esta página foi traduzida pela API Cloud Translation.

Registros do Bazel

<ph-0-0>

O Bzlmod descobre dependências solicitando as informações delas dos registros do Bazel, bancos de dados de módulos do Bazel. Atualmente, o Bzlmod só é compatível com registros de índice: diretórios locais ou servidores HTTP estáticos seguindo um formato específico.

Registro do índice

Um registro de índice é um diretório local ou um servidor HTTP estático que contém informações sobre uma lista de módulos, incluindo a página inicial, os mantenedores, o arquivo MODULE.bazel de cada versão e como buscar a origem de cada versão. Ele não precisa disponibilizar os arquivos de origem em si.

Um registro de índice precisa seguir o formato abaixo:

/bazel_registry.json: um arquivo JSON contendo metadados do registro como:
- mirrors: especificando a lista de espelhos a ser usado para arquivos de origem. O URL espelhado é uma concatenação do próprio espelho, e o URL de origem do módulo especificado pelo arquivo source.json não contém o protocolo. Por exemplo, se o URL de origem de um módulo for https://foo.com/bar/baz e mirrors contiver ["https://mirror1.com/", "https://example.com/mirror2/"], os URLs que o Bazel vai tentar testar serão https://mirror1.com/foo.com/bar/baz, https://example.com/mirror2/foo.com/bar/baz e, por fim, o próprio URL de origem original https://foo.com/bar/baz.
- module_base_path: especificando o caminho base para módulos com o tipo local_repository no arquivo source.json
/modules: um diretório que contém um subdiretório para cada módulo nesse registro
/modules/$MODULE: um diretório que contém um subdiretório para cada versão deste módulo, além de:
- metadata.json: um arquivo JSON contendo informações sobre o módulo, com os seguintes campos:
  - homepage: o URL da página inicial do projeto
  - maintainers: uma lista de objetos JSON, cada um correspondendo às informações de um administrador do módulo no registro. Observe que ele não é necessariamente igual aos autores do projeto.
  - versions: uma lista de todas as versões deste módulo encontradas neste registro
  - yanked_versions: um mapa de versões ianizadas deste módulo. As chaves precisam ser versões do yank e os valores precisam ser descrições de por que a versão é puxada, idealmente contendo um link para mais informações
/modules/$MODULE/$VERSION: um diretório que contém os seguintes arquivos:
- MODULE.bazel: o arquivo MODULE.bazel desta versão do módulo.
- source.json: um arquivo JSON contendo informações sobre como buscar a origem dessa versão do módulo.
  - O tipo padrão é "archive", que representa um repositório http_archive, com os seguintes campos:
    - url: o URL do arquivo de origem
    - integrity: a soma de verificação da Integridade de sub-recursos do arquivo.
    - strip_prefix: um prefixo de diretório a ser removido ao extrair o arquivo de origem.
    - patches: um mapa que contém arquivos de patch para aplicar ao arquivo extraído. Os arquivos de patch estão localizados no diretório /modules/$MODULE/$VERSION/patches. As chaves são os nomes dos arquivos de patch e os valores são a soma de verificação de integridade deles.
    - patch_strip: igual ao argumento --strip do patch do Unix.
    - archive_type: o tipo do arquivo transferido por download (igual a type em http_archive). Por padrão, o tipo de arquivo é determinado a partir da extensão do arquivo do URL. Se o arquivo não tiver extensão, especifique explicitamente um dos seguintes itens: "zip", "jar", "war", "aar", "tar", "tar.gz", "tgz", "tar.xz", "txz", "tar.zst", "tzst", tar.bz2, "ar" ou "deb".
  - O tipo pode ser alterado para usar um repositório Git com os seguintes campos:
    - type: git_repository
    - Os seguintes campos, conforme descrito em https://bazel.build/rules/lib/repo/git:
      - remote
      - commit
      - shallow_since
      - tag
      - init_submodules
      - verbose
      - strip_prefix
  - O tipo pode ser alterado para usar um caminho local, representando um repositório local_repository, com estes campos:
    - type: local_path
    - path: o caminho local para o repo, calculado da seguinte maneira:
      - Se path for um caminho absoluto, ele permanecerá como está
      - Se path for um caminho relativo e module_base_path for absoluto, ele será resolvido para <module_base_path>/<path>.
      - Se path e module_base_path forem caminhos relativos, ele será resolvido como <registry_path>/<module_base_path>/<path>. O registro precisa ser hospedado localmente e usado por --registry=file://<registry_path>. Caso contrário, o Bazel vai gerar um erro
- patches/: um diretório opcional que contém arquivos de patch, usado somente quando source.json tem o tipo "archive".

Registro central do Bazel

O Bazel Central Registry (BCR) em https://bcr.bazel.build/ é um registro de índice com conteúdo respaldado pelo repositório do GitHub bazelbuild/bazel-central-registry (link em inglês). Navegue pelo conteúdo usando o front-end da Web em https://registry.bazel.build/.

A comunidade do Bazel mantém o BCR, e os colaboradores são bem-vindos para enviar solicitações de envio. Consulte as diretrizes de contribuição do BCR.

Além de seguir o formato de um registro de índice normal, o BCR exige um arquivo presubmit.yml para cada versão do módulo (/modules/$MODULE/$VERSION/presubmit.yml). Esse arquivo especifica alguns destinos essenciais de criação e teste que podem ser usados para verificar a validade dessa versão do módulo. Os pipelines de CI do BCR também usam isso para garantir a interoperabilidade entre os módulos.

Seleção de registros

A flag repetível --registry do Bazel pode ser usada para especificar a lista de registros para solicitar módulos. Assim, é possível configurar seu projeto para buscar dependências de um registro interno ou de terceiros. Registros anteriores têm precedência. Por conveniência, você pode colocar uma lista de sinalizações --registry no arquivo .bazelrc do seu projeto.

Se o registro estiver hospedado no GitHub (por exemplo, como uma bifurcação de bazelbuild/bazel-central-registry), o valor --registry precisará de um endereço bruto do GitHub em raw.githubusercontent.com. Por exemplo, na ramificação main da bifurcação de my-org, defina --registry=https://raw.githubusercontent.com/my-org/bazel-central-registry/main/.

Usar a sinalização --registry impede que o Bazel Central Registry seja usado por padrão, mas é possível adicioná-lo novamente adicionando --registry=https://bcr.bazel.build.