IBM Cloud Docs
Función clone_repo()

Función clone_repo()

La función clone_repo() está diseñada para clonar un repositorio Git, incluyendo opcionalmente submódulos, con soporte para selección de rama y commit ID, así como mecanismos de reintento para manejar tiempos de espera de conexión. También sanea los mensajes de error por seguridad.

Parámetros:

  • repository : La URL del repositorio Git a clonar.
  • git_branch : La rama que se va a comprobar. Si no se proporciona, se utiliza la rama por defecto.
  • directory_name : El nombre del directorio donde se clonará el repositorio.
  • token_path : La ruta al archivo que contiene el token de autenticación Git.
  • use_submodules : (Opcional) Establecer a "1" para clonar submódulos, por defecto a "0".
  • commit_id : (Opcional) El ID de confirmación específico para restablecer después de la clonación.

Implementación de funciones:

  • Initialize Variables : Configurar variables de entorno y valores por defecto.
  • Token and User Validation : Asegúrese de que los detalles de autenticación están disponibles.
  • Clone Repository : Clonar el repositorio con mecanismo de reintento opcional.
  • Submodule Handling : Si los submódulos están habilitados, configura el entorno necesario y clona los submódulos.
  • Checkout Branch or Commit : Comprueba la rama o commit especificado.
  • Finalize and Export : Establece variables de entorno e imprime mensajes de estado.

Valor de retorno:

La función clone_repo establece varias variables/propiedades de entorno al finalizar:

  • git_branch : La rama que se ha comprobado.
  • git_commit : El ID de confirmación al que se restableció el repositorio.
  • directory_name : El directorio donde se clonó el repositorio.
  • submodules_status : Estado de los submódulos, si los hay.

Llamada a la función:

clone_repo <repo url e.g. https://github.ibm.com/owner/repo.git> <branch e.g. master> <repo directory e.g. repo_directory> <token path e.g. /path/to/token> <if submodules to be used e.g. 1> <commit id e.g. abcd1234>

Clonación de submódulos:

  • Si USE_SUBMODULES se establece en 1, el script comprueba las variables de entorno de la tubería para determinar si los submódulos deben clonarse y cómo deben configurarse.
  • La clonación de submódulos sólo admite submódulos declarados con el protocolo HTTP(S) en el archivo .gitmodules. El script se basa en el token de autenticación Git proporcionado, que se utiliza en las URL HTTP(S). Los submódulos declarados con otros protocolos, como SSH, no funcionarán sin problemas porque el script no está configurado para manejar claves SSH u otros métodos de autenticación.
  • Las variables opt-in-clone-submodules y opt-in-clone-remote-submodules desempeñan un papel crucial a la hora de determinar cómo maneja el script la clonación de submódulos.
  • opt-in-clone-submodules: Controla si los submódulos deben clonarse durante el proceso de clonación del repositorio.
    • Si opt-in-clone-submodules se establece en 1, el script incluye el parámetro --recurse-submodules en el comando Git clone, que ordena a Git inicializar y actualizar cada submódulo del repositorio.
    • Si no se establece o se establece a cualquier otro valor, los submódulos no serán clonados, y el script procederá con la clonación del repositorio principal solamente.
  • opt-in-clone-remote-submodules: Amplía el comportamiento de opt-in-clone-submodules permitiendo clonar submódulos desde sus repositorios remotos en lugar de utilizar las rutas locales especificadas en el repositorio padre.
    • Si opt-in-clone-remote-submodules se establece en 1, el script añade el parámetro --remote-submodules junto a --recurse-submodules. Esto hace que Git obtenga y clone los submódulos desde sus orígenes remotos en lugar de depender únicamente de las rutas especificadas en el repositorio padre.
    • Si no se establece o se establece a cualquier otro valor, los submódulos se clonarán utilizando las rutas locales por defecto proporcionadas en el archivo .gitmodules del repositorio padre.

Notas importantes:

  • Retry Mechanism : El script reintenta el comando de clonación hasta 5 veces con un retardo de 2 segundos entre intentos si se produce un error "Connection timed out".
  • Error Handling : Si se producen errores de autenticación u otros errores críticos, la secuencia de comandos sale con un estado distinto de cero y proporciona orientación para resolver problemas comunes.
  • Error Message Sanitisation: El script sanea los mensajes de error para asegurar que la información sensible, como los tokens de autenticación, no se exponen en la salida. Esto se hace utilizando sed para sustituir las partes sensibles de las URL por marcadores de posición.