regras de repositório git

Informar um problema Mostrar fonte Por noite · 7,4 do Google. 7.3 · 7.2 · 7.1 · 7.0 · 6.5

As seguintes funções podem ser carregadas de @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 Git, verifica a tag ou confirmação especificada e disponibiliza as metas para vinculação. Determine também o ID do o commit foi verificado e a data dele e retorna um dict com parâmetros que fornecem uma versão reproduzível da regra (na qual uma tag não necessariamente é).

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

Prefira http_archive a git_repository. Os motivos são:

As regras de repositório Git dependem do sistema git(1), enquanto o downloader HTTP é criado ao Bazel e não tem dependências de sistema.
http_archive oferece suporte a uma lista de urls como espelhos, e git_repository oferece suporte apenas um único remote.
http_archive funciona com o cache do repositório, mas não git_repository. Consulte #5116 (link em inglês) 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. Precisa ser especificado um branch, tag ou commit.
`build_file`	Rótulo: opcional O arquivo a ser usado como o arquivo BUILD para esse repositório.Esse atributo é um rótulo absoluto (use "@//" para o repositório principal). O arquivo não precisa ser nomeado 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 commit específico a ser verificado. Precisa ser especificado um 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. No entanto, -p1 geralmente será necessário para patches gerados pelo git. Quando vários argumentos -p são especificados, o último entra em vigor.Se outros argumentos diferentes de -p forem especificados, o Bazel voltará a usar a ferramenta de linha de comando "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 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 de 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 do Bazel.
`patches`	Lista de rótulos opcional Uma lista de arquivos que serão aplicados como patches depois da 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; obrigatório 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 deverá resolver essa dependência dentro do `@bar` declarado globalmente (`@bar//some:target`).
`shallow_since`	String; opcional uma data opcional, não após o commit especificado; 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, já que isso pode resultar em falhas de busca.
`strip_prefix`	String; opcional Um prefixo de diretório a ser removido dos arquivos extraídos.
`tag`	String; opcional tag no repositório remoto para 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` ou nenhum deles, mas não ambos.
`workspace_file_content`	String; opcional O conteúdo do arquivo WORKSPACE deste repositório. É possível especificar `workspace_file` ou `workspace_file_content` ou nenhum deles, mas não ambos.

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)

Clonar um repositório git externo.

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 de repositório Git dependem do sistema git(1), enquanto o downloader HTTP é criado ao Bazel e não tem dependências de sistema.
http_archive oferece suporte a uma lista de urls como espelhos, e git_repository oferece suporte apenas um único remote.
http_archive funciona com o cache do repositório, mas não git_repository. Consulte #5116 (link em inglês) 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 check-out. É preciso especificar exatamente uma das opções: branch, tag ou commit.
`build_file`	Rótulo opcional O arquivo a ser usado como o arquivo BUILD para esse repositório.Esse atributo é um rótulo absoluto (use "@//" para o repositório principal). O arquivo não precisa ser nomeado 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 commit específico a ser verificado. Precisa ser especificado um 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. No entanto, -p1 geralmente será necessário para patches gerados pelo git. Quando vários argumentos -p são especificados, o último entra em vigor.Se outros argumentos diferentes de -p forem especificados, o Bazel voltará a usar a ferramenta de linha de comando "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 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 de 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 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, ela usa a implementação de patch nativa do Bazel que não oferece suporte à correspondência de fuzz e ao patch binário. No entanto, o Bazel voltará 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".
`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; obrigatório Um dicionário do nome do repositório local para o nome do repositório global. Isso permite o controle sobre a resolução de dependências do espaço de trabalho para dependências deste 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 deverá resolver essa dependência dentro do `@bar` declarado globalmente (`@bar//some:target`).
`shallow_since`	String; opcional uma data opcional, não após o commit especificado; 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, já que isso pode resultar em falhas de busca.
`strip_prefix`	String; opcional Um prefixo de diretório a ser removido dos arquivos extraídos.
`tag`	String; opcional tag no repositório remoto para 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.