Reglas del repositorio de Git

Informar un problema Ver fuente Por la noche · 7.4 de Google Cloud. 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

Clona un repositorio de Git, verifica la etiqueta especificada o confirma. hace que sus destinos estén disponibles para la vinculación. También determina el ID del commit que se comprobó y su fecha, y muestra un diccionario con parámetros que proporcionan una versión reproducible de esta regla (que no es necesariamente una etiqueta).

Primero, Bazel intentará realizar una recuperación superficial solo de la confirmación especificada. Si eso falla (por lo general, debido a la falta de compatibilidad del servidor), recurrirá a un 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 duplicaciones, y git_repository solo admite una. 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 String; opcional

en la rama del repositorio remoto para extraerla. 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 tener el nombre (algo como BUILD.new-repo-name podría 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 String; opcional

una confirmación específica que se va a comprobar. Se debe especificar precisamente uno de los valores de 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 proporcionados 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, el último tendrá efecto.Si se especifican otros argumentos distintos de -p, Bazel recurrirá a la herramienta de línea de comandos de parches en lugar de la implementación de parches nativa de Bazel. Cuando recurras a la herramienta de línea de comandos del parche y no se especifica el atributo parche_herramienta, se utilizará “parche”.

patch_cmds Lista de cadenas; opcional

Secuencia de comandos de Bash que se aplicará en Linux/Macos después de aplicar 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, patch_cmds se ejecutará en Windows, lo que requiere que exista el binario de Bash.

patch_tool String; opcional

La utilidad patch(1) que se usará. Si lo haces, Bazel usará la herramienta de parches 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 extraerlo. 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 String; obligatorio.

El URI del repositorio remoto de Git

repo_mapping Diccionario: Cadena -> Cadena; obligatorio

Un diccionario que va del nombre del repositorio local al nombre del repositorio global. Esto permite controlar la resolución de dependencias de lugares de trabajo para las dependencias de este repositorio.

Por ejemplo, una entrada "@foo": "@bar"` declara que, en cualquier momento, este repositorio depende de `@foo` (por ejemplo, una dependencia de `@foo//some:target`, en realidad debería resolver esa dependencia dentro de `@bar`, declarada de manera global, `@bar//some:target`).

shallow_since Cadena (opcional)

Una fecha opcional, no después de la confirmación especificada. El argumento no se permite si se especifica una etiqueta o una 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 --shallow-desde de Git, no se recomienda usar este atributo, ya que puede provocar errores de recuperación.

strip_prefix Cadena (opcional)

Un prefijo de directorio para quitar los archivos extraídos.

tag Cadena (opcional)

en el repositorio remoto que se extraerán. 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 String; opcional

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

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

Clona un repositorio de Git, verifica la etiqueta especificada o confirma. hace que sus destinos estén disponibles para la vinculación. También determina el ID del commit que se comprobó y su fecha, y muestra un diccionario con parámetros que proporcionan 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 duplicaciones, y git_repository solo admite una. un solo remote.
  • http_archive funciona con la caché del repositorio, pero no git_repository Consulta #5116 para obtener más información.

Atributos

name Nombre: Obligatorio

Un nombre único para este repositorio.

branch String; opcional

en la rama del repositorio remoto para extraerla. 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 tener el nombre (algo como BUILD.new-repo-name podría 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 String; opcional

una confirmación específica que se va a comprobar. Se debe especificar precisamente uno de los valores de 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 proporcionados 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, el último tendrá efecto.Si se especifican otros argumentos distintos de -p, Bazel recurrirá a la herramienta de línea de comandos de parches en lugar de la implementación de parches nativa de Bazel. Cuando recurras a la herramienta de línea de comandos del parche y no se especifica el atributo parche_herramienta, se utilizará “parche”.

patch_cmds Lista de cadenas; opcional

Secuencia de comandos de Bash que se aplicará en Linux/Macos después de aplicar 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, patch_cmds se ejecutará en Windows, lo que requiere que exista el binario de Bash.

patch_tool String; opcional

La utilidad parche(1) que se debe usar. Si lo haces, Bazel usará la herramienta de parches 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 extraerlo. De forma predeterminada, usa la implementación de parches nativa 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 los submódulos de forma recursiva en el repositorio.

remote String; obligatorio.

El URI del repositorio de Git remoto

repo_mapping Diccionario: Cadena -> Cadena; obligatorio

Un diccionario que va del nombre del repositorio local al nombre del repositorio global. Esto permite controlar la resolución de dependencias de lugares de trabajo para las dependencias de este repositorio.

Por ejemplo, una entrada "@foo": "@bar"` declara que, en cualquier momento, este repositorio depende de `@foo` (por ejemplo, una dependencia de `@foo//some:target`, en realidad debería resolver esa dependencia dentro de `@bar`, declarada de manera global, `@bar//some:target`).

shallow_since Cadena (opcional)

Una fecha opcional, no después de la confirmación especificada. El argumento no se permite si se especifica una etiqueta o una 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 --shallow-desde de Git, no se recomienda usar este atributo, ya que puede provocar errores de recuperación.

strip_prefix Cadena (opcional)

Un prefijo de directorio para quitar los archivos extraídos.

tag Cadena (opcional)

en el repositorio remoto que se extraerán. 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 String; opcional

El contenido del archivo WORKSPACE de este repositorio. Se puede especificar "workspace_file" o "workspace_file_content", o ninguno, pero no ambos.