As seguintes funções podem ser carregadas do
@bazel_tools//tools/build_defs/repo:git.bzl
.
Regras para clonar repositórios git externos.
git_repository
git_repository(name, branch, build_file, build_file_content, commit, init_submodules, patch_args, patch_cmds, patch_cmds_win, 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 do Git, verifica a tag especificada ou confirma a propriedade e disponibiliza os destinos para vinculação. Determine também o código da confirmação realizada e a data dela, e retorne um dict com parâmetros que forneçam uma versão reproduzível dessa regra (o que uma tag não necessariamente é).
Primeiro, o Bazel tenta realizar uma busca superficial apenas da confirmação especificada. Se isso falhar, geralmente devido à ausência de suporte ao servidor, ele voltará a uma busca completa do repositório.
Prefira http_archive
a git_repository
.
Estes são os motivos:
- As regras do repositório Git dependem do sistema
git(1)
, enquanto a ferramenta de download HTTP é incorporada ao Bazel e não tem dependências do sistema. http_archive
aceita uma lista deurls
como espelhos, egit_repository
aceita apenas um únicoremote
.http_archive
funciona com o cache de repositório, mas não comgit_repository
. Consulte #5116 para mais informações.
Atributos
name |
Nome (obrigatório)
Um nome exclusivo para este repositório. |
branch |
String; opcional
branch no repositório remoto para check-out. É necessário especificar uma ramificação, tag ou confirmação. |
build_file |
Rótulo; 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 ter o nome BUILD, mas pode ser (algo como BUILD.new-repo-name pode funcionar bem para distingui-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
confirmação específica que precisa ser verificada. É necessário especificar uma ramificação, tag ou confirmação. |
init_submodules |
Booleano; opcional
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, mas geralmente será necessário -p1 para patches gerados pelo git. Se vários argumentos -p forem especificados, o último terá efeito.Se argumentos diferentes de -p forem especificados, o Bazel vai voltar a usar a ferramenta de linha de comando de patch em vez da implementação de patch nativa do Bazel. Ao voltar para a ferramenta de linha de comando patch e o atributo patch_tool não for especificado, `patch` será usado. |
patch_cmds |
Lista de strings (opcional)
Sequência de comandos Bash a serem aplicados no Linux/Macos após a aplicação dos patches. |
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 o 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 isso for especificado, o Bazel vai usar a ferramenta de patch especificada em vez da implementação de patch nativa dele. |
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 nativo do Bazel, que não é compatível com correspondência de fuzz e patch binário, mas o Bazel volta a usar a ferramenta de linha de comando de patch se o atributo "patch_tool" é especificado ou se há argumentos diferentes de "-p" no atributo "patch_args". |
recursive_init_submodules |
Booleano; opcional
Define se os submódulos serão clonados recursivamente no repositório. |
remote |
String; obrigatório
O URI do repositório Git remoto |
repo_mapping |
Dicionário: String -> String; obrigatório
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, a qualquer momento, este repositório depende de "@foo" (como uma dependência de "@foo//some:target`, ele precisa resolver essa dependência em "@bar" globalmente declarada (`@bar//some:target`). |
shallow_since |
String; opcional
uma data opcional, não depois da confirmação especificada. O argumento não será permitido se uma tag ou ramificação for especificada (o que sempre pode ser clonado com --depth=1). Definir uma data próxima à confirmação 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 check-out. É necessário especificar uma ramificação, tag ou confirmação. |
verbose |
Booleano; opcional |
workspace_file |
Rótulo; opcional
O arquivo a ser usado como o "Espaço de trabalho" para este repositório. É possível especificar "workspace_file" ou "workspace_file_content". Você não pode especificar ambos os valores. |
workspace_file_content |
String; opcional
O conteúdo do arquivo WORKSPACE deste repositório. É possível especificar "workspace_file" ou "workspace_file_content". Você não pode especificar ambos os valores. |
new_git_repository
new_git_repository(name, branch, build_file, build_file_content, commit, init_submodules, patch_args, patch_cmds, patch_cmds_win, 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 do Git, verifica a tag especificada ou confirma a propriedade e disponibiliza os destinos para vinculação. Determine também o código da confirmação realizada e a data dela, e retorne um dict com parâmetros que forneçam uma versão reproduzível dessa regra (o que uma tag não necessariamente é).
Primeiro, o Bazel tenta realizar uma busca superficial apenas da confirmação especificada. Se isso falhar, geralmente devido à ausência de suporte ao servidor, ele voltará a uma busca completa do repositório.
Prefira http_archive
a git_repository
.
Estes são os motivos:
- As regras do repositório Git dependem do sistema
git(1)
, enquanto a ferramenta de download HTTP é incorporada ao Bazel e não tem dependências do sistema. http_archive
aceita uma lista deurls
como espelhos, egit_repository
aceita apenas um únicoremote
.http_archive
funciona com o cache de repositório, mas não comgit_repository
. Consulte #5116 para mais informações.
Atributos
name |
Nome (obrigatório)
Um nome exclusivo para este repositório. |
branch |
String; opcional
branch no repositório remoto para check-out. É necessário especificar uma ramificação, tag ou confirmação. |
build_file |
Rótulo; 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 ter o nome BUILD, mas pode ser (algo como BUILD.new-repo-name pode funcionar bem para distingui-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
confirmação específica que precisa ser verificada. É necessário especificar uma ramificação, tag ou confirmação. |
init_submodules |
Booleano; opcional
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, mas geralmente será necessário -p1 para patches gerados pelo git. Se vários argumentos -p forem especificados, o último terá efeito.Se argumentos diferentes de -p forem especificados, o Bazel vai voltar a usar a ferramenta de linha de comando de patch em vez da implementação de patch nativa do Bazel. Ao voltar para a ferramenta de linha de comando patch e o atributo patch_tool não for especificado, `patch` será usado. |
patch_cmds |
Lista de strings (opcional)
Sequência de comandos Bash a serem aplicados no Linux/Macos após a aplicação dos patches. |
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 o 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 isso for especificado, o Bazel vai usar a ferramenta de patch especificada em vez da implementação de patch nativa dele. |
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 nativo do Bazel, que não é compatível com correspondência de fuzz e patch binário, mas o Bazel volta a usar a ferramenta de linha de comando de patch se o atributo "patch_tool" é especificado ou se há argumentos diferentes de "-p" no atributo "patch_args". |
recursive_init_submodules |
Booleano; opcional
Define se os submódulos serão clonados recursivamente no repositório. |
remote |
String; obrigatório
O URI do repositório Git remoto |
repo_mapping |
Dicionário: String -> String; obrigatório
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, a qualquer momento, este repositório depende de "@foo" (como uma dependência de "@foo//some:target`, ele precisa resolver essa dependência em "@bar" globalmente declarada (`@bar//some:target`). |
shallow_since |
String; opcional
uma data opcional, não depois da confirmação especificada. O argumento não será permitido se uma tag ou ramificação for especificada (o que sempre pode ser clonado com --depth=1). Definir uma data próxima à confirmação 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 check-out. É necessário especificar uma ramificação, tag ou confirmação. |
verbose |
Booleano; opcional |
workspace_file |
Rótulo; opcional
O arquivo a ser usado como o "Espaço de trabalho" para este repositório. É possível especificar "workspace_file" ou "workspace_file_content". Você não pode especificar ambos os valores. |
workspace_file_content |
String; opcional
O conteúdo do arquivo WORKSPACE deste repositório. É possível especificar "workspace_file" ou "workspace_file_content". Você não pode especificar ambos os valores. |