Gestion des sources (SCM) et déclencheurs

Intégration SCM : connecter Jenkins à votre code source

Au coeur de tout processus d'intégration continue (CI) se trouve le code source. Jenkins excelle dans l'intégration avec divers Systèmes de Gestion de Code Source (SCM, pour Source Control Management). Le plus populaire et le plus utilisé aujourd'hui est sans conteste Git, mais Jenkins supporte également d'autres SCM comme Subversion, Mercurial, etc., souvent via des plugins dédiés.

L'intégration SCM permet à Jenkins de récupérer automatiquement la dernière version de votre code (ou une branche/tag spécifique) avant de lancer un build. C'est la première étape indispensable de la plupart des pipelines : sans le code, pas de compilation, pas de tests, pas de déploiement. Jenkins doit savoir où se trouve votre dépôt, comment y accéder (credentials si nécessaire), et quelle branche ou référence récupérer.

Pour les Jobs de type "Pipeline", la configuration SCM se fait généralement au niveau du Job lui-même, dans la section "Pipeline" en choisissant "Pipeline script from SCM". Vous y spécifiez le SCM (ex: Git), l'URL du dépôt, les credentials, la branche à builder (ex: `*/main`, `*/develop`, ou même des motifs pour builder plusieurs branches), et le chemin vers votre `Jenkinsfile` (qui est `Jenkinsfile` par défaut à la racine). Lorsque le pipeline est déclenché, Jenkins effectue d'abord un `checkout` implicite de cette configuration avant d'exécuter le `Jenkinsfile`.

Focus sur Git : cloner un dépôt dans Jenkins

Git étant omniprésent, savoir configurer Jenkins pour interagir avec des dépôts Git est une compétence essentielle. Cela implique généralement l'installation du plugin Git pour Jenkins (souvent inclus dans les installations suggérées).

C'est la méthode recommandée. Dans la configuration de votre Job Pipeline :

• Allez à la section "Pipeline".
• Choisissez "Pipeline script from SCM" dans la liste déroulante "Definition".
• Dans la section SCM qui apparaît, sélectionnez "Git".
• Repositories :
  • Repository URL : Entrez l'URL de votre dépôt Git (ex: `https://github.com/votre-utilisateur/votre-projet.git` ou `git@github.com:votre-utilisateur/votre-projet.git`).
  • Credentials : Si votre dépôt est privé, sélectionnez les credentials appropriés (configurés au préalable dans "Manage Jenkins" > "Manage Credentials"). Il peut s'agir d'un couple nom d'utilisateur/mot de passe, d'un token d'accès personnel, ou d'une clé SSH.
• Branches to build :
  • Branch Specifier : Indiquez quelle(s) branche(s) Jenkins doit surveiller et builder. Exemples :
    • `*/main` : Builde la branche `main` de n'importe quel remote.
    • `*/feature/*` : Builde toutes les branches sous `feature/`.
    • Laissez vide pour utiliser la branche par défaut du dépôt (souvent `master` ou `main`).
• Script Path : Le nom du fichier contenant votre pipeline, par défaut `Jenkinsfile`.

Avec cette configuration, avant chaque exécution du pipeline, Jenkins clonera ou mettra à jour le dépôt spécifié dans son espace de travail (workspace), se positionnera sur la branche concernée, et lira le `Jenkinsfile` pour exécuter le pipeline.

Bien que le checkout principal soit géré par la configuration SCM du job, vous pourriez avoir besoin d'interagir avec Git explicitement dans vos `steps` pour des besoins plus avancés (cloner un autre dépôt, taguer, etc.).

stage('Checkout Supplémentaire') {
    steps {
        // Cloner un autre dépôt dans un sous-répertoire
        dir('module-dependant') {
            git url: 'https://github.com/autre-utilisateur/autre-projet.git', 
                branch: 'develop',
                credentialsId: 'github-credentials' // ID des credentials Jenkins
        }
        echo 'Dépôt supplémentaire cloné.'
    }
}

N'oubliez pas que l'agent Jenkins exécutant le pipeline doit avoir Git installé et accessible dans son `PATH`.

Déclencheurs de build : quand lancer vos pipelines ?

Une fois que Jenkins sait comment obtenir votre code, la question suivante est : quand doit-il lancer un build ? Jenkins offre plusieurs mécanismes de déclenchement (triggers) pour automatiser l'exécution de vos jobs et pipelines.

Ces options se configurent généralement dans l'interface de configuration du Job, dans une section nommée "Build Triggers" ou équivalent.

• Déclenchement Manuel (Build Now) :
  Ce n'est pas un déclencheur automatique, mais c'est le moyen le plus simple de lancer un job. Il suffit de cliquer sur "Lancer un build" (ou "Build Now") sur la page du job. Utile pour des tests, des exécutions ponctuelles, ou lorsque l'automatisation complète n'est pas encore en place. Les pipelines peuvent aussi avoir des paramètres d'entrée (parameters) qui sont demandés lors d'un build manuel.
• Déclenchement Périodique (Build periodically / Cron) :
  Permet de planifier l'exécution d'un job à intervalles réguliers, en utilisant une syntaxe similaire à celle de cron sur Unix. Par exemple, vous pourriez vouloir lancer un build tous les soirs à minuit pour des tests de non-régression longs, ou toutes les heures pour vérifier l'intégration.
  La syntaxe est composée de 5 champs (séparés par des espaces) : MINUTE HOUR DOM MONTH DOW (Day Of Week).
  Exemples de syntaxe cron dans Jenkins :
  • H H * * * : Une fois par jour, à une heure et minute aléatoires (H est utilisé pour répartir la charge).
  • 0 2 * * * : Tous les jours à 2h00 du matin.
  • H/15 * * * * : Toutes les 15 minutes (approximativement).
  • @daily, @hourly, @weekly, @monthly, @midnight sont aussi des alias pratiques.

  // Dans un Jenkinsfile Déclaratif (section triggers)
  pipeline {
      agent any
      triggers {
          cron('H 2 * * *') // Exécution tous les jours à 2h du matin (environ)
      }
      stages {
          // ... vos stages
      }
  }

• SCM Polling (Poll SCM) :
  Avec ce déclencheur, Jenkins interroge régulièrement votre SCM (par exemple, votre dépôt Git) à un intervalle que vous spécifiez (en utilisant la même syntaxe cron) pour détecter de nouveaux changements (commits). Si des changements sont détectés depuis le dernier build, Jenkins lance un nouveau build.
  Bien que simple à configurer, le SCM polling peut générer une charge inutile sur votre SCM si vous avez de nombreux jobs ou un intervalle de polling très court. Il y a aussi un délai entre le commit et le build.
  

  // Dans un Jenkinsfile Déclaratif (section triggers)
  pipeline {
      agent any
      triggers {
          pollSCM('H/5 * * * *') // Vérifier les changements toutes les 5 minutes (environ)
      }
      stages {
          // ... vos stages
      }
  }

• Webhook (GitHub hook trigger for GITScm polling / Generic Webhook Trigger) :
  C'est la méthode la plus efficace et la plus recommandée pour déclencher des builds en réponse à des changements dans le SCM. Au lieu que Jenkins interroge le SCM, c'est le SCM (comme GitHub, GitLab, Bitbucket) qui notifie Jenkins instantanément lorsqu'un événement se produit (par exemple, un `push` sur une branche).
  Cela nécessite une configuration côté SCM (configurer un webhook pointant vers une URL spécifique de votre instance Jenkins) et souvent un plugin côté Jenkins (comme "GitHub Integration" ou "Generic Webhook Trigger"). Jenkins écoute alors les requêtes HTTP POST sur cette URL.
  Avantages : déclenchement quasi instantané, pas de charge inutile sur le SCM par polling. La configuration exacte dépend du SCM et du plugin Jenkins utilisé. Pour GitHub, par exemple, vous activez "GitHub hook trigger for GITScm polling" dans les triggers du job, et GitHub envoie un payload à Jenkins lors d'un push.

D'autres déclencheurs existent, comme "Build after other projects are built" (déclencher un job après la réussite d'un autre), ou via des appels API distants.

Le choix du déclencheur dépend de vos besoins : rapidité de feedback, charge sur les systèmes, complexité de la configuration. Pour la plupart des projets CI/CD modernes, les webhooks sont la solution privilégiée pour une réactivité maximale aux changements de code.