Las siguientes funciones se pueden cargar desde @bazel_tools//tools/build_defs/repo:git.bzl
.
Reglas para clonar repositorios de 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)
Clona un repositorio de Git externo.
Clona un repositorio de Git, verifica la etiqueta especificada o confirma y hace que sus destinos estén disponibles para la vinculación. También determina el ID de la confirmación que realmente se procesó y su fecha, y muestra un dict con parámetros que proporcionan una versión reproducible de esta regla (no necesariamente es una etiqueta).
Primero, Bazel intentará realizar una recuperación superficial solo de la confirmación especificada. Si eso falla (en general, debido a la falta de compatibilidad con el servidor), se recurrirá a una recuperación completa del repositorio.
Prefiere http_archive
en lugar de git_repository
.
Estos son los motivos:
- Las reglas del repositorio de Git dependen del sistema
git(1)
, mientras que el software de descarga de HTTP está integrado en Bazel y no tiene dependencias del sistema. http_archive
admite una lista deurls
como duplicaciones, ygit_repository
admite solo unaremote
.http_archive
funciona con la caché del repositorio, pero no congit_repository
. Consulta #5116 para obtener más información.
Atributos
name |
Nombre (obligatorio)
Un nombre único para este repositorio. |
branch |
String; opcional
en el repositorio remoto para pagar. Se debe especificar con precisión una 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.new-repo-name puede funcionar bien para distinguirlo de los archivos BUILD reales del repositorio. |
build_file_content |
String; opcional
El contenido del archivo BUILD para este repositorio |
commit |
String; opcional
una confirmación específica. Se debe especificar con precisión una rama, etiqueta o confirmación. |
init_submodules |
Booleano; opcional
Indica si se deben clonar los submódulos en el repositorio. |
patch_args |
Lista de cadenas; opcional
Los argumentos dados a la herramienta de parche. El valor predeterminado es -p0; sin embargo, por lo general, -p1 será necesario para los parches generados por Git. Si se especifican varios argumentos -p, se aplicará el último.Si se especifican otros argumentos que no sean -p, Bazel recurrirá a la herramienta de línea de comandos de parche en lugar de la implementación de parches nativa de Bazel. Si se recurre a la herramienta de línea de comandos del parche y el atributo "patch_tool" no se especifican, se usará "patch". |
patch_cmds |
Lista de cadenas; opcional
Secuencia de comandos de Bash que se aplicarán en Linux/Macos después de la aplicación de los parches. |
patch_cmds_win |
Lista de cadenas; opcional
Secuencia de comandos de PowerShell que se aplicarán en Windows después de aplicar los parches. Si no se establece este atributo, se ejecutará patch_cmds en Windows, que requiere el objeto binario Bash para existir. |
patch_tool |
String; opcional
La utilidad del parche(1) que se usará. Si se especifica esto, Bazel usará la herramienta de parche especificada en lugar de la implementación de parches nativa de Bazel. |
patches |
Lista de etiquetas (opcional)
Una lista de los archivos que se aplicarán como parches después de extraer el archivo. De forma predeterminada, usa la implementación del parche nativo de Bazel, que no admite la coincidencia de fuzz ni el parche binario, pero Bazel recurrirá a la herramienta de línea de comandos de parche 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 submódulos de manera recursiva en el repositorio. |
remote |
String; obligatoria
El URI del repositorio de Git remoto |
repo_mapping |
Diccionario: String -> String; obligatorio
Un diccionario que va desde el nombre del repositorio local hasta el nombre del repositorio global. Esto permite controles sobre la resolución de dependencias del lugar de trabajo para las dependencias de este repositorio. Por ejemplo, una entrada"@foo": "@bar" declara que, para cualquier momento, este repositorio depende de `@foo` (como una dependencia de `@foo//some:target`, en realidad debería resolver esa dependencia dentro de `@bar` declarado globalmente (`@bar//some:target`). |
shallow_since |
String; opcional
una fecha opcional, no posterior a la confirmación especificada; no se permite el argumento si se especifica una etiqueta o una rama (que siempre se puede clonar con --depth=1). Configurar una fecha cercana a la confirmación especificada podría 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 errores de recuperación. |
strip_prefix |
String; opcional
Un prefijo de directorio para quitar de los archivos extraídos. |
tag |
String; opcional
en el repositorio remoto para extraerla. Se debe especificar con precisión una 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 bien ninguno, pero no ambos. |
workspace_file_content |
String; opcional
El contenido del archivo WORKSPACE de este repositorio. Se puede especificar `workspace_file` o `workspace_file_content`, o bien ninguno, pero no 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)
Clona un repositorio de Git externo.
Clona un repositorio de Git, verifica la etiqueta especificada o confirma y hace que sus destinos estén disponibles para la vinculación. También determina el ID de la confirmación que realmente se procesó y su fecha, y muestra un dict con parámetros que proporcionan una versión reproducible de esta regla (no necesariamente es una etiqueta).
Primero, Bazel intentará realizar una recuperación superficial solo de la confirmación especificada. Si eso falla (en general, debido a la falta de compatibilidad con el servidor), se recurrirá a una recuperación completa del repositorio.
Prefiere http_archive
en lugar de git_repository
.
Estos son los motivos:
- Las reglas del repositorio de Git dependen del sistema
git(1)
, mientras que el software de descarga de HTTP está integrado en Bazel y no tiene dependencias del sistema. http_archive
admite una lista deurls
como duplicaciones, ygit_repository
admite solo unaremote
.http_archive
funciona con la caché del repositorio, pero no congit_repository
. Consulta #5116 para obtener más información.
Atributos
name |
Nombre (obligatorio)
Un nombre único para este repositorio. |
branch |
String; opcional
en el repositorio remoto para pagar. Se debe especificar con precisión una 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.new-repo-name puede funcionar bien para distinguirlo de los archivos BUILD reales del repositorio. |
build_file_content |
String; opcional
El contenido del archivo BUILD para este repositorio |
commit |
String; opcional
una confirmación específica. Se debe especificar con precisión una rama, etiqueta o confirmación. |
init_submodules |
Booleano; opcional
Indica si se deben clonar los submódulos en el repositorio. |
patch_args |
Lista de cadenas; opcional
Los argumentos dados a la herramienta de parche. El valor predeterminado es -p0; sin embargo, por lo general, -p1 será necesario para los parches generados por Git. Si se especifican varios argumentos -p, se aplicará el último.Si se especifican otros argumentos que no sean -p, Bazel recurrirá a la herramienta de línea de comandos de parche en lugar de la implementación de parches nativa de Bazel. Si se recurre a la herramienta de línea de comandos del parche y el atributo "patch_tool" no se especifican, se usará "patch". |
patch_cmds |
Lista de cadenas; opcional
Secuencia de comandos de Bash que se aplicarán en Linux/Macos después de la aplicación de los parches. |
patch_cmds_win |
Lista de cadenas; opcional
Secuencia de comandos de PowerShell que se aplicarán en Windows después de aplicar los parches. Si no se establece este atributo, se ejecutará patch_cmds en Windows, que requiere el objeto binario Bash para existir. |
patch_tool |
String; opcional
La utilidad del parche(1) que se usará. Si se especifica esto, Bazel usará la herramienta de parche especificada en lugar de la implementación de parches nativa de Bazel. |
patches |
Lista de etiquetas (opcional)
Una lista de los archivos que se aplicarán como parches después de extraer el archivo. De forma predeterminada, usa la implementación del parche nativo de Bazel, que no admite la coincidencia de fuzz ni el parche binario, pero Bazel recurrirá a la herramienta de línea de comandos de parche 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 submódulos de manera recursiva en el repositorio. |
remote |
String; obligatoria
El URI del repositorio de Git remoto |
repo_mapping |
Diccionario: String -> String; obligatorio
Un diccionario que va desde el nombre del repositorio local hasta el nombre del repositorio global. Esto permite controles sobre la resolución de dependencias del lugar de trabajo para las dependencias de este repositorio. Por ejemplo, una entrada"@foo": "@bar" declara que, para cualquier momento, este repositorio depende de `@foo` (como una dependencia de `@foo//some:target`, en realidad debería resolver esa dependencia dentro de `@bar` declarado globalmente (`@bar//some:target`). |
shallow_since |
String; opcional
una fecha opcional, no posterior a la confirmación especificada; no se permite el argumento si se especifica una etiqueta o una rama (que siempre se puede clonar con --depth=1). Configurar una fecha cercana a la confirmación especificada podría 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 errores de recuperación. |
strip_prefix |
String; opcional
Un prefijo de directorio para quitar de los archivos extraídos. |
tag |
String; opcional
en el repositorio remoto para extraerla. Se debe especificar con precisión una 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 bien ninguno, pero no ambos. |
workspace_file_content |
String; opcional
El contenido del archivo WORKSPACE de este repositorio. Se puede especificar `workspace_file` o `workspace_file_content`, o bien ninguno, pero no ambos. |