regras de repositório git

As funções a seguir podem ser carregadas de @bazel_tools//tools/build_defs/repo:git.bzl.

Regras para clonar repositórios Git externos.

git_repository

load("@bazel//tools/build_defs/repo:git.bzl", "git_repository")

git_repository(name, branch, build_file, build_file_content, commit, init_submodules, patch_args,
               patch_cmds, patch_cmds_win, patch_strip, patch_tool, patches,
               recursive_init_submodules, remote, repo_mapping, shallow_since, strip_prefix, tag,
               verbose, workspace_file, workspace_file_content)

Clone um repositório Git externo.

Clona um repositório Git, verifica a tag ou confirmação especificada e disponibiliza as metas para vinculação. Também determina o ID do commit realmente verificado e a data dele e retorna um dicionário com parâmetros que fornecem uma versão reproduzível dessa regra (que uma tag não é necessariamente necessária).

O Bazel primeiro tenta fazer uma busca superficial apenas do commit especificado. Se isso falhar (geralmente devido à falta de suporte do servidor), ele vai voltar para uma busca completa do repositório.

Prefira http_archive a git_repository. Os motivos são:

• As regras do repositório do Git dependem do git(1) do sistema, enquanto o downloader HTTP é integrado ao Bazel e não tem dependências do sistema.
• http_archive oferece suporte a uma lista de urls como espelhos, e git_repository oferece suporte apenas a uma única remote.
• O http_archive funciona com o cache do repositório, mas não com o git_repository. Consulte #5116 para mais informações.

ATRIBUTOS

name	Nome: obrigatório Um nome exclusivo para este repositório.
branch	String; opcional no repositório remoto para ser verificado. É preciso especificar exatamente uma das opções: branch, tag ou commit.
build_file	Rótulo: opcional O arquivo a ser usado como BUILD para este repositório.Esse atributo é um rótulo absoluto (use "@//" para o repositório principal). O arquivo não precisa ser chamado de BUILD, mas pode ser. Algo como BUILD.new-repo-name pode ser útil para diferenciá-lo dos arquivos BUILD reais do repositório.
build_file_content	String; opcional O conteúdo do arquivo BUILD para este repositório.
commit	String; opcional commit específico a ser verificado. É preciso especificar exatamente uma das opções: branch, tag ou commit.
init_submodules	Booleano; opcional Define se os submódulos serão clonados no repositório.
patch_args	Lista de strings; opcional Os argumentos fornecidos à ferramenta de patch. O padrão é -p0 (consulte o atributo "patch_strip"). No entanto, -p1 geralmente será 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 de patch em vez da implementação de patch nativa do Bazel. Quando a ferramenta de linha de comando de patch e o atributo patch_tool não forem especificados, o "patch" será usado.
patch_cmds	Lista de strings; opcional Sequência de comandos do 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 depois que os patches forem aplicados. Se esse atributo não for definido, o patch_cmds será executado no Windows, o que exige que o binário do Bash exista.
patch_strip	Número inteiro; opcional Quando definido como "N", isso equivale a inserir "-pN" no início de "patch_args".
patch_tool	String; opcional O utilitário de patch(1) a ser usado. Se esse valor for especificado, o Bazel vai usar a ferramenta de patch especificada em vez da implementação de patch nativa do Bazel.
patches	Lista de identificadores: 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 de fuzz e patch binário, mas o Bazel vai usar a ferramenta de linha de comando de patch se o atributo "patch_tool" for especificado ou se houver argumentos diferentes de "-p" no atributo "patch_args".
recursive_init_submodules	Booleano; opcional Define se os submódulos serão clonados de forma recursiva no repositório.
remote	String; obrigatório O URI do repositório Git remoto
repo_mapping	Dicionário: String -> String; opcional No contexto "WORKSPACE": um dicionário do nome do repositório local para o nome do repositório global. Isso permite o controle da 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 esse repositório depender de@foo (como uma dependência de@foo//some:target, ele precisa resolver essa dependência dentro de@bar declarado globalmente ("@bar//some:target"). Esse atributo _não_ tem suporte no contexto "MODULE.bazel" (ao invocar uma regra de repositório dentro da função de implementação de uma extensão de módulo).
shallow_since	String; opcional uma data opcional, não após a confirmação especificada. O argumento não é permitido se uma tag ou ramificação for especificada (que sempre pode ser clonada com --depth=1). A definição de uma data próxima à especificada pode permitir um clone superficial do repositório, mesmo que o servidor não ofereça suporte a buscas superficiais de confirmações arbitrárias. Devido a bugs na implementação --shallow-since do git, o uso desse atributo não é recomendado, porque pode resultar em falhas de busca.
strip_prefix	String; opcional Um prefixo de diretório para remover dos arquivos extraídos.
tag	String; opcional tag no repositório remoto para fazer o check-out. É preciso especificar exatamente uma das opções: branch, tag ou commit.
verbose	Booleano; opcional
workspace_file	Rótulo: opcional O arquivo a ser usado como "WORKSPACE" para este repositório. É possível especificar "workspace_file" ou "workspace_file_content", 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", mas não ambos.

new_git_repository

load("@bazel//tools/build_defs/repo:git.bzl", "new_git_repository")

new_git_repository(name, branch, build_file, build_file_content, commit, init_submodules,
                   patch_args, patch_cmds, patch_cmds_win, patch_strip, patch_tool, patches,
                   recursive_init_submodules, remote, repo_mapping, shallow_since, strip_prefix, tag,
                   verbose, workspace_file, workspace_file_content)

Clone um repositório Git externo.

Clona um repositório Git, verifica a tag ou confirmação especificada e disponibiliza as metas para vinculação. Também determina o ID do commit realmente verificado e a data dele e retorna um dicionário com parâmetros que fornecem uma versão reproduzível dessa regra (que uma tag não é necessariamente necessária).

O Bazel primeiro tenta fazer uma busca superficial apenas do commit especificado. Se isso falhar (geralmente devido à falta de suporte do servidor), ele vai voltar para uma busca completa do repositório.

Prefira http_archive a git_repository. Os motivos são:

• As regras do repositório do Git dependem do git(1) do sistema, enquanto o downloader HTTP é integrado ao Bazel e não tem dependências do sistema.
• http_archive oferece suporte a uma lista de urls como espelhos, e git_repository oferece suporte apenas a uma única remote.
• O http_archive funciona com o cache do repositório, mas não com o git_repository. Consulte #5116 para mais informações.

ATRIBUTOS

name	Nome: obrigatório Um nome exclusivo para este repositório.
branch	String; opcional no repositório remoto para fazer o check-out. É preciso especificar exatamente uma das opções: branch, tag ou commit.
build_file	Rótulo: opcional O arquivo a ser usado como BUILD para este repositório.Esse atributo é um rótulo absoluto (use "@//" para o repositório principal). O arquivo não precisa ser chamado de BUILD, mas pode ser. Algo como BUILD.new-repo-name pode ser útil para diferenciá-lo dos arquivos BUILD reais do repositório.
build_file_content	String; opcional O conteúdo do arquivo BUILD para este repositório.
commit	String; opcional commit específico a ser verificado. É preciso especificar exatamente uma das opções: branch, tag ou commit.
init_submodules	Booleano; opcional Define se os submódulos serão clonados no repositório.
patch_args	Lista de strings; opcional Os argumentos fornecidos à ferramenta de patch. O padrão é -p0 (consulte o atributo "patch_strip"). No entanto, -p1 geralmente será 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 de patch em vez da implementação de patch nativa do Bazel. Quando a ferramenta de linha de comando de patch e o atributo patch_tool não forem especificados, o "patch" será usado.
patch_cmds	Lista de strings; opcional Sequência de comandos do 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 depois que os patches forem aplicados. Se esse atributo não for definido, o patch_cmds será executado no Windows, o que exige que o binário do Bash exista.
patch_strip	Número inteiro; opcional Quando definido como "N", isso equivale a inserir "-pN" no início de "patch_args".
patch_tool	String; opcional O utilitário de patch(1) a ser usado. Se esse valor for especificado, o Bazel vai usar a ferramenta de patch especificada em vez da implementação de patch nativa do Bazel.
patches	Lista de identificadores: 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 de fuzz e patch binário, mas o Bazel vai usar a ferramenta de linha de comando de patch se o atributo "patch_tool" for especificado ou se houver argumentos diferentes de "-p" no atributo "patch_args".
recursive_init_submodules	Booleano; opcional Define se os submódulos serão clonados de forma recursiva no repositório.
remote	String; obrigatório O URI do repositório Git remoto
repo_mapping	Dicionário: String -> String; opcional No contexto "WORKSPACE": um dicionário do nome do repositório local para o nome do repositório global. Isso permite o controle da 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 esse repositório depender de@foo (como uma dependência de@foo//some:target, ele precisa resolver essa dependência dentro de@bar declarado globalmente ("@bar//some:target"). Esse atributo _não_ tem suporte no contexto "MODULE.bazel" (ao invocar uma regra de repositório dentro da função de implementação de uma extensão de módulo).
shallow_since	String; opcional uma data opcional, não após a confirmação especificada. O argumento não é permitido se uma tag ou ramificação for especificada (que sempre pode ser clonada com --depth=1). A definição de uma data próxima à especificada pode permitir um clone superficial do repositório, mesmo que o servidor não ofereça suporte a buscas superficiais de confirmações arbitrárias. Devido a bugs na implementação --shallow-since do git, o uso desse atributo não é recomendado, porque pode resultar em falhas de busca.
strip_prefix	String; opcional Um prefixo de diretório para remover dos arquivos extraídos.
tag	String; opcional tag no repositório remoto para fazer o check-out. É preciso especificar exatamente uma das opções: branch, tag ou commit.
verbose	Booleano; opcional
workspace_file	Rótulo: opcional O arquivo a ser usado como "WORKSPACE" para este repositório. É possível especificar "workspace_file" ou "workspace_file_content", 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", mas não ambos.