
Lancer le Pipeline et analyser la sortie console
Apprenez à lancer un pipeline Jenkins et à interpréter sa sortie console. Guide essentiel pour déboguer et comprendre l'exécution de vos automatisations CI/CD.
L'exécution du pipeline : du clic à l'automatisation en action
Une fois que votre job de type Pipeline est créé et que son Jenkinsfile est correctement configuré (soit directement dans l'interface, soit via SCM), l'étape suivante est de le mettre en action : lancer son exécution. Ce processus, souvent appelé "build" dans la terminologie Jenkins même pour un pipeline, va déclencher la lecture et l'interprétation de votre Jenkinsfile, et l'exécution séquentielle des étapes que vous y avez définies.
Comprendre comment lancer un pipeline et où trouver les informations sur son déroulement est fondamental. La sortie console, en particulier, est votre principale source d'information pour suivre la progression, identifier les succès, et diagnostiquer les problèmes. C'est un peu la "boîte noire" de votre pipeline.
Comment lancer manuellement un pipeline Jenkins ?
Pour lancer un pipeline manuellement (ce qui est typique pour un premier test ou des exécutions ponctuelles), suivez ces étapes simples :
- Naviguer vers le job Pipeline : Depuis le tableau de bord Jenkins, cliquez sur le nom du job Pipeline que vous souhaitez exécuter. Vous arriverez sur la page principale de ce job.
- Trouver l'option de lancement : Sur la page du job, dans le menu de gauche, vous devriez voir une option intitulée "Lancer un build" (ou "Build Now" en anglais). Cliquez sur ce lien.
- Build avec paramètres (optionnel) : Si votre pipeline est configuré pour accepter des paramètres (par exemple, choisir une branche spécifique à builder, ou une option de déploiement), une page intermédiaire s'affichera pour vous permettre de saisir ces paramètres. Si aucun paramètre n'est défini, le build démarrera immédiatement.
Dès que vous cliquez sur "Lancer un build" (ou validez les paramètres), Jenkins met en file d'attente une nouvelle exécution de votre pipeline. Si un agent compatible est disponible, le build commencera rapidement. Vous verrez alors apparaître une nouvelle entrée dans l'historique des builds (généralement une section "Build History" ou "Historique des builds" sur la page du job), avec un numéro de build incrémental (par exemple, #1, #2, etc.) et une icône indiquant son statut (par exemple, une sphère bleue clignotante pour un build en cours, bleue fixe pour un succès, rouge pour un échec).
Accéder et interpréter la sortie console du pipeline
La sortie console est l'endroit où Jenkins enregistre tous les messages générés pendant l'exécution de votre pipeline. Cela inclut les sorties des commandes echo de votre Jenkinsfile, les logs des commandes sh ou bat, les messages d'erreur, et les informations de progression de Jenkins lui-même. C'est une ressource inestimable pour le suivi et le débogage.
Pour accéder à la sortie console d'un build spécifique :
- Sélectionner le build : Dans l'historique des builds sur la page de votre job, cliquez sur le numéro du build qui vous intéresse (par exemple, le dernier build que vous venez de lancer).
- Ouvrir la sortie console : Sur la page du build sélectionné, cherchez dans le menu de gauche un lien intitulé "Sortie de la console" (ou "Console Output"). Cliquez dessus.
Vous verrez alors un flux de texte, souvent coloré, qui représente le log complet de l'exécution du pipeline. Voici quelques éléments clés à rechercher et à comprendre dans cette sortie :
- Horodatage : Chaque ligne de log est généralement précédée d'un horodatage, ce qui vous aide à suivre la séquence des événements et à mesurer la durée des opérations.
- Messages
echo: Les messages que vous avez inclus avecechodans votre Jenkinsfile apparaîtront ici. C'est un bon moyen de marquer le début et la fin des étapes ou d'afficher des variables. - Exécution des commandes (
sh,bat) : Lorsque Jenkins exécute une commande shell ou batch, la commande elle-même est souvent affichée (précédée d'un+ou d'un symbole similaire), suivie de sa sortie standard (stdout) et de sa sortie d'erreur (stderr). - Statut des étapes (Stages) : Jenkins affiche souvent des messages indiquant le début et la fin de chaque
stagedéfini dans votre Jenkinsfile. Dans l'interface "Stage View" ou Blue Ocean, ces étapes sont également visualisées graphiquement. - Messages d'erreur : Si une commande échoue (par exemple,
mvn testtrouve des tests en échec, ou une commandenpm installne trouve pas un paquet), l'erreur sera typiquement affichée en évidence (souvent en rouge). Le message d'erreur est crucial pour comprendre pourquoi une étape a échoué. Il est souvent accompagné d'une trace de la pile (stack trace) pour les erreurs de programmation. - Statut final : A la fin de la sortie console, vous trouverez un message indiquant le statut final du build (par exemple,
Finished: SUCCESS,Finished: FAILURE,Finished: ABORTED).
Lors de l'analyse de la sortie console :
- Commencez par la fin : Si un build échoue, les messages d'erreur les plus pertinents se trouvent souvent vers la fin de la sortie console, juste avant le message indiquant l'échec.
- Recherchez des mots-clés : Utilisez la fonction de recherche de votre navigateur (Ctrl+F ou Cmd+F) pour rechercher des termes comme "ERROR", "FAILURE", "WARN", ou des noms de fichiers ou de commandes spécifiques qui pourraient être liés au problème.
- Observez le contexte : Ne vous contentez pas de lire la ligne d'erreur isolée. Regardez les quelques lignes qui précèdent et suivent pour comprendre le contexte dans lequel l'erreur s'est produite.
- Soyez attentif aux codes de sortie : Une commande
shoubatqui échoue renvoie généralement un code de sortie non nul. Jenkins l'indiquera et marquera l'étape comme échouée. Par exemple,script returned exit code 1. - Comparez avec des builds réussis : Si vous avez des builds précédents qui ont réussi, comparer leur sortie console avec celle d'un build échoué peut parfois aider à identifier ce qui a changé ou mal tourné.
Maîtriser la lecture de la sortie console est une compétence essentielle pour tout utilisateur de Jenkins. C'est votre principal outil de diagnostic. Avec l'expérience, vous apprendrez à repérer rapidement les informations pertinentes et à interpréter les messages d'erreur pour résoudre les problèmes de vos pipelines.
Autres outils d'analyse : Stage View et Blue Ocean
En plus de la sortie console brute, Jenkins offre des vues plus structurées pour analyser l'exécution d'un pipeline :
- Stage View (Vue des Etapes) : Disponible sur la page principale du job et sur la page de chaque build, cette vue affiche chaque
stagede votre pipeline comme une colonne. La couleur de la colonne indique le statut de l'étape (vert pour succès, rouge pour échec, bleu pour en cours, gris pour ignoré). Vous pouvez cliquer sur une étape pour voir les logs spécifiques à cette étape, ce qui est souvent plus ciblé que de parcourir toute la sortie console. - Blue Ocean : Si le plugin Blue Ocean est installé sur votre instance Jenkins, il propose une interface utilisateur moderne et visuellement attrayante pour visualiser vos pipelines. Il offre une représentation graphique claire des étapes, des exécutions parallèles, et facilite la navigation dans les logs et les artefacts. Pour les pipelines complexes, Blue Ocean peut grandement améliorer l'expérience d'analyse.
Ces outils graphiques complètent la sortie console en fournissant une vue d'ensemble de la progression et en permettant de naviguer plus facilement vers les sections problématiques. Cependant, pour une analyse détaillée et la compréhension fine des erreurs, la sortie console reste la source de vérité ultime.