Déclencheurs de build : manuel, périodique (cron), SCM polling, webhook

L'art de démarrer un build : les déclencheurs Jenkins

Une fois que votre Job ou Pipeline Jenkins est configuré pour récupérer le code source (SCM) et exécuter des actions, la question cruciale devient : quand ce processus doit-il être lancé ? C'est là qu interviennent les déclencheurs de build (Build Triggers). Jenkins offre une panoplie de mécanismes pour initier un build, allant de l'intervention manuelle à des automatisations sophistiquées basées sur des événements externes ou des planifications temporelles.

Choisir le bon déclencheur (ou la bonne combinaison de déclencheurs) est essentiel pour une chaîne CI/CD efficace. Un déclenchement trop fréquent peut surcharger les ressources, tandis qu'un déclenchement trop rare peut retarder le feedback aux développeurs. Cette section détaille les principaux types de déclencheurs : manuel, périodique (cron), SCM polling, et webhook, en expliquant leur fonctionnement, leurs cas d'usage, et comment les configurer.

La configuration des déclencheurs se fait généralement dans l'interface de configuration du Job. Pour les Pipelines Déclaratifs, certains triggers peuvent aussi être définis directement dans le `Jenkinsfile` via la directive triggers { ... }.

Déclenchement Manuel : le contrôle total

Le moyen le plus direct de lancer un Job ou un Pipeline est le déclenchement manuel.

• Tests initiaux : Lors de la création ou de la modification d'un Job, pour vérifier rapidement sa configuration.
• Déploiements contrôlés : Pour des déploiements manuels en production après validation, ou pour des montées de version spécifiques.
• Tâches ponctuelles : Pour des jobs qui effectuent des tâches d'administration ou de maintenance qui ne nécessitent pas d'automatisation complète.
• Jobs paramétrés : Si votre pipeline est configuré avec des paramètres (via la directive parameters dans le `Jenkinsfile` ou la section "Ce projet est paramétré" dans la configuration d'un Job Freestyle), Jenkins demandera ces paramètres à l'utilisateur avant de lancer le build. Exemples de paramètres : la version à déployer, l'environnement cible, une option de configuration spécifique.

// Exemple de paramètres dans un Jenkinsfile Déclaratif
pipeline {
    agent any
    parameters {
        string(name: 'VERSION', defaultValue: '1.0.0', description: 'Version à builder/déployer')
        choice(name: 'ENVIRONMENT', choices: ['staging', 'production'], description: 'Environnement cible')
        booleanParam(name: 'RUN_EXTRA_TESTS', defaultValue: false, description: 'Exécuter les tests étendus ?')
    }
    stages {
        stage('Build') {
            steps {
                echo "Version: ${params.VERSION}, Environnement: ${params.ENVIRONMENT}, Tests étendus: ${params.RUN_EXTRA_TESTS}"
                // ... logique de build utilisant les paramètres
            }
        }
    }
}

Le déclenchement manuel est simple et direct, mais pour une véritable automatisation CI/CD, on se tournera vers des déclencheurs plus autonomes.

Déclenchement Périodique (Cron) : l'automatisation planifiée

Le déclenchement périodique permet de planifier l'exécution d'un Job à des moments spécifiques ou à intervalles réguliers, en utilisant une syntaxe inspirée de l'utilitaire cron des systèmes Unix.

Caractères spéciaux :

• * : correspond à toutes les valeurs valides pour le champ.
• M-N : correspond à une plage de valeurs.
• M,N,P : correspond à une liste de valeurs.
• */X ou H/X : correspond à toutes les X unités (ex: */15 pour les minutes = toutes les 15 minutes).
• H (pour "Hash") : Permet de répartir la charge. Au lieu de spécifier une valeur exacte (ex: 0 pour l'heure), H est remplacé par une valeur calculée en fonction du nom du job, assurant que tous les jobs planifiés avec H ne démarrent pas exactement en même temps. Par exemple, H H * * * signifie une fois par jour, mais à une heure et minute différentes pour chaque job.

• 0 2 * * * : Tous les jours à 2h00 du matin.
• H/30 * * * * : Toutes les 30 minutes environ.
• H(0-29)/15 * * * * : Toutes les 15 minutes durant la première demi-heure de chaque heure.
• 0 8,18 * * 1-5 : A 8h00 et 18h00, du lundi au vendredi.
• Des alias sont aussi disponibles : @hourly, @daily, @weekly, @monthly, @midnight.

• Builds nocturnes (nightly builds) pour des tests complets ou des analyses de code.
• Génération de rapports périodiques.
• Tâches de maintenance régulières.
• Synchronisation de données.

pipeline {
    agent any
    triggers {
        cron('H 22 * * 1-5') // Tous les soirs de la semaine à 22h (environ)
    }
    stages { /* ... */ }
}

Le déclenchement périodique est fiable mais ne réagit pas aux changements de code.

SCM Polling : surveiller les changements de code

Le SCM Polling (ou "Poll SCM") est un mécanisme où Jenkins interroge régulièrement votre Système de Gestion de Code Source (SCM, ex: Git) pour détecter si de nouveaux changements (commits) ont été poussés depuis le dernier build.

• Déclencher un build automatiquement après un commit, lorsque les webhooks ne sont pas configurables ou souhaités.
• Alternative simple aux webhooks si la réactivité immédiate n'est pas critique.

pipeline {
    agent any
    triggers {
        pollSCM('H/2 * * * *') // Vérifier les changements toutes les 2 minutes (environ)
    }
    stages { /* ... */ }
}

• Charge sur le SCM : Des interrogations fréquentes par de nombreux jobs peuvent surcharger le serveur SCM.
• Délai : Il y a toujours un délai (jusqu'à la fin de l'intervalle de polling) entre le moment où le code est poussé et le moment où Jenkins lance le build.
• Moins efficace que les webhooks : Les webhooks sont généralement préférés pour une réactivité instantanée et une moindre charge.

SCM Polling est une option viable si les webhooks sont difficiles à mettre en place, mais songez à l'impact sur votre SCM.

Webhook : la notification instantanée par le SCM

Le webhook est la méthode la plus moderne et la plus efficace pour déclencher des builds Jenkins en réponse à des événements dans votre SCM (typiquement un `git push`).

1. Côté Jenkins :
   • Dans la configuration du Job, activez le déclencheur approprié. Pour les dépôts Git hébergés sur des plateformes comme GitHub, le plugin "GitHub Integration" (ou des plugins similaires pour GitLab, Bitbucket) simplifie cela. Souvent, il suffit de cocher une option comme "GitHub hook trigger for GITScm polling" (le nom est un peu trompeur, car il ne fait pas de polling mais écoute le hook). Pour des besoins plus génériques, le plugin "Generic Webhook Trigger" est très puissant et flexible, permettant de déclencher des builds et d'extraire des informations du payload JSON du webhook.
   • Assurez-vous que votre instance Jenkins est accessible depuis Internet (ou du moins depuis le serveur SCM) sur l'URL du webhook.
2. Côté SCM (ex: GitHub) :
   • Dans les paramètres de votre dépôt (Settings > Webhooks), ajoutez un nouveau webhook.
   • Payload URL : Entrez l'URL que Jenkins écoute. Pour le plugin GitHub, c'est souvent `JENKINS_URL/github-webhook/`. Pour Generic Webhook Trigger, c'est `JENKINS_URL/generic-webhook-trigger/invoke`.
   • Content type : Généralement `application/json`.
   • Secret (Optionnel mais recommandé) : Un secret partagé entre le SCM et Jenkins pour vérifier l'authenticité de la requête webhook.
   • Events : Choisissez les événements qui doivent déclencher le webhook (ex: "Pushes", "Pull request events", etc.).

• Réactivité maximale : Le build est déclenché quasi instantanément après le push.
• Efficacité : Pas de charge inutile sur le SCM due au polling. Jenkins ne travaille que lorsqu'il y a réellement quelque chose à faire.
• Richesse d'informations : Le payload du webhook contient souvent des informations détaillées sur l'événement (auteur du commit, message, fichiers modifiés, etc.) que des plugins comme Generic Webhook Trigger peuvent extraire et utiliser comme paramètres de build.

Le choix et la configuration des déclencheurs sont essentiels pour adapter Jenkins à votre flux de travail et garantir une automatisation CI/CD réactive et efficiente.