Nettoyer régulièrement l'espace de travail (workspace) et les artefacts

L'importance de l'hygiène numérique dans Jenkins : workspaces et artefacts

Dans le cycle de vie d'un projet géré par Jenkins, chaque exécution d'un job (un "build") génère des données. La plus évidente est le code source récupéré depuis le système de gestion de version (SCM), qui réside dans un répertoire appelé espace de travail (workspace) sur l'agent exécutant le build. De plus, le processus de build lui-même produit souvent des artefacts – des fichiers résultants tels que des binaires compilés (JAR, WAR, EXE), des images Docker, des rapports de tests, de la documentation, etc. – que Jenkins peut archiver et conserver. Si ces données ne sont pas gérées et nettoyées correctement, elles peuvent s'accumuler rapidement, conduisant à une série de problèmes.

Une bonne hygiène de l'environnement Jenkins, incluant le nettoyage régulier des workspaces et la gestion de la rétention des artefacts et des historiques de build, est cruciale pour maintenir une instance performante, stable et fiable. Négliger cet aspect, c'est s'exposer à des pannes dues à la saturation de l'espace disque, à des builds lents ou pollués, et à une complexité croissante dans la gestion de l'infrastructure.

Ce chapitre va explorer les stratégies et les outils fournis par Jenkins pour maintenir un environnement propre. Nous verrons comment configurer la suppression des anciens builds, comment nettoyer les workspaces avant ou après l'exécution d'un build, et pourquoi ces pratiques sont essentielles pour la santé à long terme de votre système CI/CD.

Les risques liés à l'accumulation des données de build

L'absence d'une stratégie de nettoyage pour les workspaces et les artefacts peut entraîner plusieurs conséquences néfastes :

1. Saturation de l'espace disque : C'est le risque le plus direct et le plus visible. Les workspaces, surtout pour des projets volumineux ou ceux qui téléchargent de nombreuses dépendances, peuvent occuper des gigaoctets. Les artefacts archivés, si conservés indéfiniment pour chaque build, s'accumulent également sur le disque du master Jenkins (ou sur un stockage externe si configuré). Une fois l'espace disque plein sur un agent ou sur le master, Jenkins ne pourra plus exécuter de nouveaux builds, voire deviendra instable ou inaccessible.

2. Pollution des builds et non-reproductibilité : Si un workspace n'est pas nettoyé entre les builds d'un même job, des fichiers résiduels d'une exécution précédente peuvent interférer avec la suivante. Par exemple, des fichiers compilés non supprimés pourraient être inclus dans un nouveau package, ou des résultats de tests obsolètes pourraient être pris en compte. Cela peut conduire à des builds qui réussissent localement mais échouent sur Jenkins (ou l'inverse), ou à des erreurs de build difficiles à diagnostiquer car l'environnement n'est pas propre et prédictible.

3. Ralentissement des opérations : Des workspaces très volumineux peuvent ralentir certaines opérations, notamment le checkout du code source depuis le SCM si celui-ci doit mettre à jour un grand nombre de fichiers. La navigation dans les historiques de build sur l'interface Jenkins peut également devenir plus lente si des milliers de builds et leurs artefacts sont conservés.

4. Augmentation des coûts de stockage et de sauvegarde : Plus de données stockées signifient plus d'espace disque nécessaire (ce qui a un coût) et des sauvegardes du master Jenkins plus volumineuses et plus longues à réaliser.

5. Complexité de la gestion : Sans politique de nettoyage, la surveillance manuelle de l'espace disque et le nettoyage ad-hoc deviennent des tâches chronophages et réactives, plutôt que proactives.

Gérer la rétention des builds et des artefacts archivés

Jenkins offre des mécanismes pour contrôler combien de temps les enregistrements des builds (logs, résultats de tests, etc.) et leurs artefacts archivés sont conservés. Cette configuration se fait généralement au niveau de chaque Job.

Dans l'interface de configuration d'un Job (Freestyle, Pipeline, etc.), l'option la plus courante est "Discard old builds" (Supprimer les anciens builds). Elle permet de définir une stratégie de rotation basée sur :

• Days to keep builds : Nombre de jours pendant lesquels conserver les builds. Jenkins supprimera les builds plus anciens que cette durée.
• Max # of builds to keep : Nombre maximum de builds à conserver. Jenkins supprimera les builds les plus anciens au-delà de ce nombre.

Vous pouvez spécifier l'un ou l'autre, ou les deux (Jenkins appliquera alors la condition qui se produit en premier ou la plus restrictive, selon l'interprétation). Il existe aussi des options avancées pour s'assurer de toujours garder le dernier build stable, le dernier build réussi, etc.

Dans un `Jenkinsfile` Déclaratif, cette configuration se fait via la directive `options` avec `buildDiscarder` et `logRotator` :

pipeline {
    agent any
    options {
        // Conserver les builds des 7 derniers jours, OU au maximum les 20 derniers builds.
        // S'assurer de toujours garder au moins le dernier build réussi.
        buildDiscarder(
            logRotator(
                daysToKeepStr: '7',
                numToKeepStr: '20',
                artifactDaysToKeepStr: '', // Conserver les artefacts aussi longtemps que le build
                artifactNumToKeepStr: ''   // Conserver les artefacts aussi longtemps que le build
            )
        )
        // Pour toujours garder le dernier build stable/réussi, les options avancées de logRotator peuvent être utilisées,
        // ou en ne spécifiant rien, Jenkins tend à garder le dernier build stable.
    }
    stages {
        stage('Build') {
            steps {
                echo 'Building...'
                // Exemple d'archivage d'artefacts
                archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
            }
        }
    }
}

Il est important de noter que la suppression des anciens builds entraîne également la suppression des artefacts qui leur étaient associés et qui ont été archivés par Jenkins (via `archiveArtifacts` par exemple). Si vous avez besoin de conserver des artefacts spécifiques sur une plus longue durée (par exemple, les releases officielles), vous devriez envisager de les publier dans un gestionnaire d'artefacts dédié (comme Nexus, Artifactory, ou un bucket S3) en dehors de Jenkins, plutôt que de compter uniquement sur l'archivage de Jenkins.

Stratégies pour le nettoyage des espaces de travail (workspaces)

Le nettoyage du workspace est crucial pour garantir que chaque build s'exécute dans un environnement propre et prédictible, évitant la pollution par des fichiers résiduels. Jenkins propose plusieurs approches :

Exemple pour le plugin Git dans un `Jenkinsfile` avec le step `checkout` :

stage('Checkout') {
    steps {
        // Option 1: Nettoyer avant le checkout (supprime les fichiers non suivis, réinitialise les modifications locales)
        checkout([
            $class: 'GitSCM',
            branches: [[name: env.BRANCH_NAME]],
            doGenerateSubmoduleConfigurations: false,
            extensions: [ [$class: 'CleanCheckout'] ], // Nettoie avant
            // extensions: [ [$class: 'CleanBeforeCheckout'] ], // Alternative, plus agressive
            submoduleCfg: [],
            userRemoteConfigs: [[credentialsId: 'git-credentials-id', url: 'https://github.com/user/repo.git']]
        ])

        // Option 2: Supprimer tout le workspace avant le checkout (plus radical, garantit un clone frais)
        // deleteDir() // Supprime le contenu du workspace courant
        // git url: 'https://github.com/user/repo.git', credentialsId: 'git-credentials-id', branch: env.BRANCH_NAME
    }
}

pipeline {
    agent any
    stages {
        // ... vos étapes de build ...
        stage('Build and Test') {
            steps {
                sh 'mvn clean package'
            }
        }
    }
    post {
        always {
            echo "Nettoyage du workspace après le build."
            cleanWs() // Supprime tout le contenu du workspace
            // Options pour cleanWs() :
            // cleanWs deleteDirs: true // Supprime aussi les répertoires vides à la racine du workspace après nettoyage
            // cleanWs notFailBuild: true // N'échoue pas le build si le nettoyage échoue (par défaut, il échoue)
            // cleanWs patterns: [[pattern: '**/tempFiles/**', type: 'INCLUDE']] // Ne nettoie que certains patterns
        }
    }
}

Le step `cleanWs()` est fourni par le plugin "Workspace Cleanup". Assurez-vous qu'il est installé. Il est puissant et permet de supprimer l'intégralité du workspace.

Le choix de la stratégie (avant, après, ou les deux) et de la méthode (option SCM, `deleteDir()`, `cleanWs()`, plugin Workspace Cleanup) dépend de vos besoins spécifiques. Cependant, un nettoyage systématique après chaque build avec `cleanWs()` dans le bloc `post always` est une excellente pratique de base. Pour les builds critiques où la propreté absolue est requise, un nettoyage avant le checkout SCM peut également être envisagé, bien que cela puisse légèrement augmenter le temps de checkout si un clone frais est toujours nécessaire.