Intégration avec Git : cloner un dépôt

L'importance de Git dans l'écosystème Jenkins

Git est aujourd'hui le système de gestion de code source (SCM) le plus répandu dans le monde du développement logiciel. Son adoption massive en fait un partenaire naturel pour Jenkins dans la mise en place de chaînes d'intégration et de déploiement continus (CI/CD). La capacité de Jenkins à interagir nativement avec les dépôts Git est donc une fonctionnalité fondamentale. Cette intégration permet à Jenkins de récupérer (cloner ou mettre à jour) le code source d'une application avant de procéder aux étapes de build, de test et de déploiement.

Pour que Jenkins puisse communiquer avec Git, le plugin Git pour Jenkins doit être installé. Il est généralement inclus dans les installations recommandées de Jenkins. De plus, l'outil Git en ligne de commande doit être installé et accessible sur les agents Jenkins qui exécuteront les builds nécessitant une interaction avec Git.

Cette section se concentrera sur les méthodes pour cloner un dépôt Git dans le contexte d'un Job Jenkins, que ce soit via la configuration SCM du job pour un pipeline ou via des steps spécifiques dans un `Jenkinsfile`.

Méthode principale : configuration SCM pour les Jobs Pipeline

Pour les Jobs de type "Pipeline" où le script du pipeline est lui-même stocké dans un dépôt Git (l'approche "Pipeline script from SCM"), Jenkins gère le clonage initial du dépôt de manière quasi transparente. Voici comment cette configuration est typiquement mise en place :

• Repository URL : Entrez l'URL complète de votre dépôt Git. Cela peut être une URL HTTPS (ex: `https://github.com/votre-utilisateur/votre-projet.git`) ou une URL SSH (ex: `git@github.com:votre-utilisateur/votre-projet.git`). L'URL SSH nécessite une configuration de clés SSH pour l'utilisateur Jenkins sur l'agent.
• Credentials : Si votre dépôt est privé, vous devez fournir des identifiants. Cliquez sur "Add" à côté de "Credentials" pour ajouter de nouveaux identifiants ou sélectionnez des identifiants existants. Jenkins supporte plusieurs types d'identifiants pour Git :
  • Username with password : Un nom d'utilisateur et un mot de passe (ou un Personal Access Token pour des plateformes comme GitHub/GitLab).
  • SSH Username with private key : Un nom d'utilisateur (souvent `git`) et la clé SSH privée de l'utilisateur Jenkins, dont la clé publique correspondante a été ajoutée aux clés de déploiement ou au compte utilisateur sur la plateforme Git.
  • Secret text : Pour d'autres types de tokens ou secrets.
  Les credentials sont stockés de manière sécurisée par Jenkins.
• Branches to build (Branch Specifier) : Spécifiez quelle(s) branche(s) Jenkins doit récupérer et utiliser pour trouver le `Jenkinsfile`. Par défaut, c'est souvent `*/master` ou `*/main`. Vous pouvez utiliser des wildcards comme `*/feature/*` pour builder toutes les branches sous `feature/`, ou `*/release-*` pour les branches de release. Si vous voulez builder toutes les branches (pour les pipelines multi-branches), vous pouvez utiliser `**`.
• Repository browser (Optionnel) : Vous pouvez configurer un explorateur de dépôt (comme celui fourni par GitHub ou GitLab) pour que Jenkins puisse générer des liens directs vers les commits, les diffs, etc., dans l'interface des builds.
• Additional Behaviours (Optionnel mais souvent utile) : Cliquez sur "Add" pour explorer des comportements additionnels :
  • Clean before checkout / Clean after checkout : Pour s'assurer que l'espace de travail est propre avant de cloner ou après. Utile pour éviter des conflits dus à des fichiers résiduels.
  • Prune stale remote-tracking branches : Supprime les références aux branches distantes qui n'existent plus.
  • Sparse checkout paths : Pour ne cloner que certains sous-répertoires du dépôt, utile pour les monorepos très volumineux.
  • Advanced clone behaviours : Permet de spécifier un timeout pour le clonage, d'activer le clonage superficiel (shallow clone) pour ne récupérer que l'historique récent et économiser de l'espace et du temps (ex: `Depth: 1`).
• Script Path : Le chemin vers votre `Jenkinsfile` dans le dépôt. Par défaut, c'est `Jenkinsfile` à la racine du dépôt.

1. Allouer un agent (selon la configuration agent dans le `Jenkinsfile` si disponible, ou un agent par défaut sinon pour cette phase initiale de checkout).
2. Sur cet agent, dans l'espace de travail (workspace) du Job, exécuter les commandes Git nécessaires pour cloner le dépôt (si c'est le premier build) ou le mettre à jour (fetch/pull) pour les builds suivants, en se basant sur la branche spécifiée.
3. Une fois le code source (incluant le `Jenkinsfile`) récupéré, Jenkins lira et interprétera le `Jenkinsfile` pour exécuter les étapes (stages et steps) définies dans le pipeline.

Cette méthode est la plus courante et la plus robuste pour les pipelines dont la définition est versionnée.

Utilisation des steps checkout scm et git dans un Jenkinsfile

Même si le checkout principal est géré comme décrit ci-dessus, il peut y avoir des situations où vous avez besoin de cloner un dépôt (ou une partie d'un dépôt) explicitement à l'intérieur de vos steps dans un `Jenkinsfile`.

pipeline {
    agent any
    // Si le SCM est configuré au niveau du job,
    // le checkout initial est généralement implicite.
    // Mais on peut le rendre explicite ou le répéter :
    stages {
        stage('Checkout Source') {
            steps {
                echo 'Checking out SCM defined in job configuration...'
                checkout scm // Utilise la configuration SCM du Job
                sh 'ls -la' // Vérifier les fichiers clonés
            }
        }
        // ... autres stages
    }
}

stage('Clone Additional Library') {
    steps {
        echo 'Cloning an additional utility library...'
        // Cloner dans le répertoire courant du workspace
        git url: 'https://github.com/some-org/utility-library.git', 
            branch: 'v1.2',
            credentialsId: 'optional-github-credentials' // Si le dépôt est privé

        // Cloner dans un sous-répertoire spécifique
        dir('external-service') {
            git url: 'git@gitlab.com:my-group/external-service-client.git', 
                branch: 'main',
                credentialsId: 'gitlab-ssh-key'
        }
        sh 'ls -la utility-library external-service' 
    }
}

Paramètres courants pour le step git :

• url: (Obligatoire) L'URL du dépôt Git.
• branch: La branche à cloner (par défaut, la branche principale du dépôt distant).
• credentialsId: L'ID d'un credential stocké dans Jenkins, à utiliser si le dépôt est privé.
• changelog: (Booléen, par défaut `true`) Si true, calcule et affiche les changements depuis le dernier build.
• poll: (Booléen, par défaut `true`) Si true et si le SCM polling est activé pour le job, ce checkout sera pris en compte pour la détection de changements. Généralement, on le met à false pour des checkouts secondaires afin de ne pas déclencher de builds inutilement.

En maîtrisant ces différentes façons d'intégrer et de cloner des dépôts Git, vous assurez que vos pipelines Jenkins ont toujours accès au code source nécessaire pour effectuer leurs tâches d'automatisation.