Paramètres :

• repository : L'URL du dépôt Git à cloner.
• git_branch : La branche à extraire. Si elle n'est pas fournie, la branche par défaut est utilisée.
• directory_name : Le nom du répertoire où le dépôt sera cloné.
• token_path : Le chemin d'accès au fichier contenant le jeton d'authentification Git.
• use_submodules : (Facultatif) Défini à "1" pour cloner les sous-modules, la valeur par défaut est "0".
• commit_id : (Facultatif) L'identifiant spécifique du commit à réinitialiser après le clonage.

Mise en œuvre de la fonction :

• Initialize Variables : Définition des variables d'environnement et des valeurs par défaut.
• Token and User Validation : S'assurer que les détails de l'authentification sont disponibles.
• Clone Repository : Cloner le référentiel avec un mécanisme de réessai optionnel.
• Submodule Handling : Si les sous-modules sont activés, mettre en place l'environnement nécessaire et cloner les sous-modules.
• Checkout Branch or Commit : Vérifier la branche ou le commit spécifié.
• Finalize and Export : Définir les variables d'environnement et imprimer les messages d'état.

Valeur de retour :

La fonction clone_repo définit plusieurs variables/propriétés d'environnement lorsqu'elle est terminée :

• git_branch : La branche qui a été extraite.
• git_commit : L'ID du commit auquel le dépôt a été réinitialisé.
• directory_name : Le répertoire dans lequel le dépôt a été cloné.
• submodules_status : Statut des sous-modules, le cas échéant.

Appel de fonction :

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>

Clonage de sous-modules :

• Si USE_SUBMODULES est défini sur 1, le script vérifie les variables d'environnement du pipeline pour déterminer si les sous-modules doivent être clonés et comment ils doivent être configurés.
• Le clonage de sous-modules ne prend en charge que les sous-modules déclarés avec le protocole HTTP(S) dans le fichier .gitmodules. Le script s'appuie sur le jeton d'authentification Git fourni, qui est utilisé dans les URL HTTP(S). Les sous-modules déclarés avec d'autres protocoles, tels que SSH, ne fonctionneront pas de manière transparente car le script n'est pas configuré pour gérer les clés SSH ou d'autres méthodes d'authentification.
• Les variables opt-in-clone-submodules et opt-in-clone-remote-submodules jouent un rôle crucial dans la manière dont le script gère le clonage des sous-modules.
• opt-in-clone-submodules : Contrôle si les sous-modules doivent être clonés pendant le processus de clonage du référentiel.
  • Si opt-in-clone-submodules est défini sur 1, le script inclut le paramètre --recurse-submodules dans la commande Git clone, qui demande à Git d'initialiser et de mettre à jour chaque sous-module dans le référentiel.
  • S'il n'est pas défini ou s'il est défini à une autre valeur, les sous-modules ne seront pas clonés et le script procédera au clonage du référentiel principal uniquement.
• opt-in-clone-remote-submodules : étend le comportement de opt-in-clone-submodules en permettant aux sous-modules d'être clonés à partir de leurs référentiels distants plutôt que d'utiliser les chemins locaux spécifiés dans le référentiel parent.
  • Si opt-in-clone-remote-submodules est défini comme 1, le script ajoute le paramètre --remote-submodules à côté de --recurse-submodules. Cela permet à Git de récupérer et de cloner les sous-modules à partir de leurs origines distantes plutôt que de s'appuyer uniquement sur les chemins spécifiés dans le référentiel parent.
  • S'il n'est pas défini ou s'il est défini à une autre valeur, les sous-modules seront clonés en utilisant les chemins locaux par défaut fournis dans le fichier .gitmodules du référentiel parent.