Reglas del repositorio de Git

Las siguientes funciones se pueden cargar desde @bazel_tools//tools/build_defs/repo:git.bzl.

Son reglas para clonar repositorios de 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_tool, patches, recursive_init_submodules, remote,
               repo_mapping, shallow_since, strip_prefix, tag, verbose, workspace_file,
               workspace_file_content)

Clona un repositorio de git externo.

Clona un repositorio de Git, verifica la etiqueta especificada o confirma, y pone sus destinos a disposición para la vinculación. Además, determina el ID de la confirmación que se verificó y su fecha, y muestra un diccionario con parámetros que proporcionen una versión reproducible de esta regla (que no es necesariamente una etiqueta).

Bazel primero intentará realizar una recuperación superficial solo de la confirmación especificada. Si eso falla (por lo general, debido a que falta compatibilidad con el servidor), se recurrirá a una recuperación completa del repositorio.

Se prefiere http_archive a git_repository. Estos son los motivos:

Las reglas del repositorio de Git dependen del git(1) del sistema, mientras que el descargador de HTTP se compila en Bazel y no tiene dependencias del sistema.
http_archive admite una lista de urls como espejos, y git_repository solo admite un solo remote.
http_archive funciona con la caché del repositorio, pero no con git_repository. Consulta #5116 para obtener más información.

ATRIBUTOS

`name`	Nombre: Obligatorio Un nombre único para este repositorio.
`branch`	Cadena (opcional) en el repositorio remoto que se va a consultar. Se debe especificar precisamente uno de los valores de rama, etiqueta o confirmación.
`build_file`	Etiqueta (opcional) Es el archivo que se usará como archivo BUILD para este repositorio. Este atributo es una etiqueta absoluta (usa "@//" para el repositorio principal). No es necesario que el archivo se llame BUILD, pero puede serlo (algo como BUILD.nombre-nuevo-del-repositorio puede funcionar bien para distinguirlo de los archivos BUILD reales del repositorio.
`build_file_content`	Cadena (opcional) El contenido del archivo Build de este repositorio.
`commit`	Cadena (opcional) una confirmación específica que se va a comprobar. Se debe especificar exactamente una de las siguientes opciones: rama, etiqueta o confirmación.
`init_submodules`	Booleano; opcional Establece si se deben clonar submódulos en el repositorio.
`patch_args`	Lista de cadenas (opcional) Los argumentos que se le proporcionan a la herramienta de parches El valor predeterminado es -p0, pero, por lo general, se necesitará -p1 para los parches que genera git. Si se especifican varios argumentos -p, se aplicará el último.Si se especifican argumentos distintos de -p, Bazel usará la herramienta de línea de comandos de parches en lugar de la implementación de parches nativa de Bazel. Cuando se recurra a la herramienta de línea de comandos de parche y no se especifique el atributo patch_tool, se usará "patch".
`patch_cmds`	Lista de cadenas (opcional) Es la secuencia de comandos de Bash que se aplicará en Linux/MacOS después de aplicar los parches.
`patch_cmds_win`	Lista de cadenas (opcional) Es la secuencia de comandos de PowerShell que se aplicará en Windows después de aplicar los parches. Si no se establece este atributo, patch_cmds se ejecutará en Windows, lo que requiere que exista el binario de Bash.
`patch_tool`	Cadena (opcional) La utilidad parche(1) que se usará. Si se especifica esto, Bazel usará la herramienta de parches especificada en lugar de la implementación de parches nativa de Bazel.
`patches`	Lista de etiquetas (opcional) Es una lista de archivos que se aplicarán como parches después de extraer el archivo. De forma predeterminada, usa la implementación de parches nativa de Bazel, que no admite la coincidencia difusa ni el parche binario, pero Bazel recurrirá a usar la herramienta de línea de comandos de parches si se especifica el atributo "patch_tool" o si hay argumentos distintos de "-p" en el atributo "patch_args".
`recursive_init_submodules`	Booleano (opcional) Indica si se deben clonar los submódulos de forma recursiva en el repositorio.
`remote`	Cadena; obligatorio El URI del repositorio de Git remoto
`repo_mapping`	Diccionario: Cadena -> Cadena (opcional) Solo en el contexto "WORKSPACE": Un diccionario del nombre del repositorio local al nombre del repositorio global. Esto permite controlar la resolución de dependencias de Workspace para las dependencias de este repositorio. Por ejemplo, una entrada "@foo": "@bar" declara que, cada vez que este repositorio dependa de "@foo" (como una dependencia de "@foo//some:target", en realidad debería resolver esa dependencia dentro de "@bar" declarado globalmente ("@bar//some:target"). Este atributo _no_ es compatible con el contexto "MODULE.bazel" (cuando se invoca una regla de repositorio dentro de la función de implementación de una extensión de módulo).
`shallow_since`	Cadena (opcional) una fecha opcional, no posterior a la confirmación especificada; el argumento no está permitido si se especifica una etiqueta o rama (que siempre se puede clonar con --depth=1). Establecer una fecha cercana a la confirmación especificada puede permitir una clonación superficial del repositorio incluso si el servidor no admite recuperaciones superficiales de confirmaciones arbitrarias. Debido a errores en la implementación de --shallow-since de git, no se recomienda usar este atributo, ya que puede provocar fallas de recuperación.
`strip_prefix`	Cadena (opcional) Es un prefijo de directorio que se quitará de los archivos extraídos.
`tag`	Cadena (opcional) etiqueta en el repositorio remoto para que se marque como extraída. Se debe especificar exactamente una de las siguientes opciones: rama, etiqueta o confirmación.
`verbose`	Booleano; opcional
`workspace_file`	Etiqueta (opcional) Es el archivo que se usará como archivo "WORKSPACE" para este repositorio. Se puede especificar "workspace_file" o "workspace_file_content", o ninguno, pero no ambos.
`workspace_file_content`	Cadena (opcional) Es el contenido del archivo WORKSPACE de este repositorio. Se puede especificar "workspace_file" o "workspace_file_content", o ninguno, pero no 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_tool, patches,
                   recursive_init_submodules, remote, repo_mapping, shallow_since, strip_prefix, tag,
                   verbose, workspace_file, workspace_file_content)

Clonar un repositorio de Git externo

Primero, Bazel intentará realizar una recuperación superficial solo de la confirmación especificada. Si eso falla (por lo general, debido a que falta compatibilidad con el servidor), se recurrirá a una recuperación completa del repositorio.

Se prefiere http_archive a git_repository. Estos son los motivos:

Las reglas del repositorio de Git dependen del git(1) del sistema, mientras que el descargador de HTTP se compila en Bazel y no tiene dependencias del sistema.
http_archive admite una lista de urls como duplicados, y git_repository admite solo un remote.
http_archive funciona con la caché del repositorio, pero no con git_repository. Consulta #5116 para obtener más información.

ATRIBUTOS

`name`	Name; obligatorio Un nombre único para este repositorio.
`branch`	Cadena (opcional) en el repositorio remoto que se va a consultar. Se debe especificar exactamente una de las siguientes opciones: rama, etiqueta o confirmación.
`build_file`	Etiqueta (opcional) Es el archivo que se usará como archivo BUILD para este repositorio. Este atributo es una etiqueta absoluta (usa "@//" para el repositorio principal). No es necesario que el archivo se llame BUILD, pero puede serlo (algo como BUILD.nombre-nuevo-del-repositorio puede funcionar bien para distinguirlo de los archivos BUILD reales del repositorio.
`build_file_content`	Cadena (opcional) El contenido del archivo Build de este repositorio.
`commit`	Cadena (opcional) una confirmación específica que se va a comprobar. Se debe especificar exactamente una de las siguientes opciones: rama, etiqueta o confirmación.
`init_submodules`	Booleano; opcional Establece si se deben clonar submódulos en el repositorio.
`patch_args`	Lista de cadenas (opcional) Los argumentos que se le proporcionan a la herramienta de parches El valor predeterminado es -p0, pero, por lo general, se necesitará -p1 para los parches que genera git. Si se especifican varios argumentos -p, se aplicará el último.Si se especifican argumentos distintos de -p, Bazel usará la herramienta de línea de comandos de parches en lugar de la implementación de parches nativa de Bazel. Cuando se recurra a la herramienta de línea de comandos de parche y no se especifique el atributo patch_tool, se usará "patch".
`patch_cmds`	Lista de cadenas (opcional) Es la secuencia de comandos de Bash que se aplicará en Linux/MacOS después de aplicar los parches.
`patch_cmds_win`	Lista de cadenas (opcional) Es la secuencia de comandos de PowerShell que se aplicará en Windows después de aplicar los parches. Si no se establece este atributo, patch_cmds se ejecutará en Windows, lo que requiere que exista el binario de Bash.
`patch_tool`	Cadena (opcional) La utilidad parche(1) que se usará. Si se especifica esto, Bazel usará la herramienta de parches especificada en lugar de la implementación de parches nativa de Bazel.
`patches`	Lista de etiquetas (opcional) Es una lista de archivos que se aplicarán como parches después de extraer el archivo. De forma predeterminada, usa la implementación de parches nativa de Bazel, que no admite la coincidencia difusa ni el parche binario, pero Bazel recurrirá a usar la herramienta de línea de comandos de parches si se especifica el atributo "patch_tool" o si hay argumentos distintos de "-p" en el atributo "patch_args".
`recursive_init_submodules`	Booleano (opcional) Indica si se deben clonar los submódulos de forma recursiva en el repositorio.
`remote`	Cadena; obligatorio El URI del repositorio de Git remoto
`repo_mapping`	Diccionario: Cadena -> Cadena (opcional) Solo en el contexto "WORKSPACE": Un diccionario del nombre del repositorio local al nombre del repositorio global. Esto permite controlar la resolución de dependencias de Workspace para las dependencias de este repositorio. Por ejemplo, una entrada "@foo": "@bar" declara que, cada vez que este repositorio dependa de "@foo" (como una dependencia de "@foo//some:target", en realidad debería resolver esa dependencia dentro de "@bar" declarado globalmente ("@bar//some:target"). Este atributo _no_ es compatible con el contexto "MODULE.bazel" (cuando se invoca una regla de repositorio dentro de la función de implementación de una extensión de módulo).
`shallow_since`	Cadena (opcional) una fecha opcional, no posterior a la confirmación especificada; el argumento no está permitido si se especifica una etiqueta o rama (que siempre se puede clonar con --depth=1). Establecer una fecha cercana a la confirmación especificada puede permitir una clonación superficial del repositorio incluso si el servidor no admite recuperaciones superficiales de confirmaciones arbitrarias. Debido a errores en la implementación de --shallow-since de git, no se recomienda usar este atributo, ya que puede provocar fallas de recuperación.
`strip_prefix`	Cadena (opcional) Es un prefijo de directorio que se quitará de los archivos extraídos.
`tag`	Cadena (opcional) etiqueta en el repositorio remoto para que se marque como extraída. Se debe especificar exactamente una de las siguientes opciones: rama, etiqueta o confirmación.
`verbose`	Booleano (opcional)
`workspace_file`	Etiqueta (opcional) El archivo que se usará como archivo `WORKSPACE` para este repositorio. Se puede especificar “workspace_file” o “workspace_file_content”, o ninguno, pero no ambos.
`workspace_file_content`	Cadena (opcional) Es el contenido del archivo WORKSPACE de este repositorio. Se puede especificar "workspace_file" o "workspace_file_content", o ninguno, pero no ambos.