Explorer d'autres types de steps (archivage d'artefacts, notifications)

Au-delà des bases : enrichir vos pipelines avec des steps fonctionnels

Après avoir maîtrisé les steps fondamentaux comme echo, git, et sh, il est temps d'explorer d'autres types de steps qui ajoutent une valeur significative à vos pipelines Jenkins. Deux catégories de steps particulièrement importantes pour des processus CI/CD matures sont celles liées à la gestion des produits de build (les artefacts) et à la communication de l'état des builds (les notifications). Intégrer ces steps rendra vos pipelines plus utiles, traçables et collaboratifs.

L'archivage d'artefacts permet de conserver les résultats importants de vos builds – comme des fichiers exécutables, des bibliothèques, des rapports de tests ou de la documentation – directement dans Jenkins. Cela facilite leur accès, leur téléchargement, et leur utilisation par d'autres processus ou équipes. Les notifications, quant à elles, sont cruciales pour informer rapidement les parties prenantes des succès, des échecs ou de l'instabilité des builds, permettant une réactivité accrue.

Cette section vous guidera à travers la découverte et l'utilisation de ces steps, en se concentrant sur leur syntaxe dans un Jenkinsfile Déclaratif et sur les cas d'usage courants. Comprendre et implémenter ces fonctionnalités vous permettra de construire des pipelines qui ne se contentent pas d'exécuter des scripts, mais qui gèrent activement leurs résultats et communiquent leur état de manière proactive.

Archivage d'artefacts avec le step `archiveArtifacts`

Le step archiveArtifacts est essentiel pour sauvegarder les fichiers générés par votre processus de build. Sans archivage, ces fichiers seraient typiquement perdus une fois l'espace de travail (workspace) du build nettoyé. Les artefacts archivés sont stockés par Jenkins et associés à une exécution spécifique du build, ce qui permet de les retrouver facilement.

La syntaxe de base du step archiveArtifacts dans un Jenkinsfile est la suivante :

steps {
    // ... autres steps de build qui génèrent des fichiers ...
    archiveArtifacts artifacts: 'chemin/vers/vos/artefacts/*.jar, rapports/**/*.html'
}

Dans cet exemple :

• artifacts: '...' : C'est l'argument principal où vous spécifiez les fichiers à archiver. Vous pouvez utiliser des motifs de style Ant (wildcards) pour sélectionner plusieurs fichiers ou des répertoires. Par exemple, *.jar archive tous les fichiers JAR à la racine du workspace, et rapports/**/*.html archive tous les fichiers HTML dans le répertoire rapports et ses sous-répertoires.

Il existe d'autres options pour archiveArtifacts, comme :

• fingerprint: true : Pour activer le "fingerprinting" des artefacts, ce qui permet de suivre leur utilisation à travers différents Jobs.
• allowEmptyArchive: true : Pour ne pas faire échouer le build si aucun fichier ne correspond aux motifs spécifiés. Utile si la génération d'artefacts est conditionnelle.
• onlyIfSuccessful: true : (Comportement par défaut) Pour n'archiver les artefacts que si le build est un succès.

Vous placeriez typiquement le step archiveArtifacts à la fin d'un stage de build ou de packaging, après que les fichiers désirés aient été créés. Par exemple, après une compilation Java qui produit un .jar, ou après l'exécution de tests qui génèrent des rapports HTML.

stage('Build et Package') {
    steps {
        sh 'mvn package' // Supposons que cela crée un target/myapp.jar et des rapports dans target/surefire-reports
        archiveArtifacts artifacts: 'target/*.jar, target/surefire-reports/**/*.html'
    }
}

Une fois archivés, les artefacts sont accessibles depuis la page du build dans l'interface Jenkins classique (et souvent aussi via Blue Ocean).

Envoyer des notifications : le step `mail` et les alternatives

Informer les équipes de l'état des builds est crucial. Le step mail est un moyen simple d'envoyer des notifications par email. Pour l'utiliser, le service de messagerie doit être configuré dans les paramètres globaux de Jenkins ("Gérer Jenkins" > "Configurer le système" > section "Mailer" ou "Notification par E-mail").

Voici un exemple d'utilisation du step mail dans la section post d'un pipeline, qui s'exécute après la complétion des stages :

pipeline {
    agent any
    stages {
        // ... vos stages ici ...
    }
    post {
        always {
            echo "Le build ${currentBuild.fullDisplayName} est terminé."
        }
        success {
            mail to: 'equipe-dev@example.com', 
                 subject: "SUCCES: Pipeline ${env.JOB_NAME} - Build #${env.BUILD_NUMBER}", 
                 body: "Le pipeline ${env.JOB_NAME} s'est terminé avec succès. Détails : ${env.BUILD_URL}"
        }
        failure {
            mail to: 'equipe-dev@example.com, responsable-qa@example.com', 
                 subject: "ECHEC: Pipeline ${env.JOB_NAME} - Build #${env.BUILD_NUMBER}", 
                 body: "Le pipeline ${env.JOB_NAME} a échoué. Veuillez investiguer : ${env.BUILD_URL}"
        }
        unstable {
            mail to: 'equipe-dev@example.com', 
                 subject: "INSTABLE: Pipeline ${env.JOB_NAME} - Build #${env.BUILD_NUMBER}", 
                 body: "Le pipeline ${env.JOB_NAME} est instable (tests échoués ?). Détails : ${env.BUILD_URL}"
        }
    }
}

Dans cet exemple :

• to: '...' : Liste des destinataires (séparés par des virgules).
• subject: '...' : L'objet de l'email. L'utilisation de variables d'environnement Jenkins comme ${env.JOB_NAME}, ${env.BUILD_NUMBER}, et ${env.BUILD_URL} est très courante pour contextualiser le message. ${currentBuild.fullDisplayName} est une autre variable utile.
• body: '...' : Le corps de l'email. Peut contenir du HTML simple pour le formatage.

Bien que le step mail soit pratique, de nombreuses équipes préfèrent des notifications plus interactives via des plateformes de messagerie instantanée. Des plugins populaires existent pour Slack (slackSend), Microsoft Teams, etc. Ces plugins fournissent leurs propres steps avec des options de configuration spécifiques pour envoyer des messages formatés, incluant des couleurs et des liens, directement dans les canaux de discussion de l'équipe. Par exemple, avec le plugin Slack :

post {
    failure {
        slackSend channel: '#ci-alerts', 
                  color: 'danger', 
                  message: "Pipeline *${env.JOB_NAME}* - Build _#${env.BUILD_NUMBER}_ a échoué :  ${env.BUILD_URL}"
    }
}

L'exploration de ces steps d'archivage et de notification, ainsi que leur intégration judicieuse dans vos pipelines, augmentera considérablement l'efficacité de vos processus CI/CD. Ils permettent de passer d'une simple exécution de code à un système d'intégration et de livraison bien géré et communicant.