Symptôme → solution la plus rapide : si votre Jenkins Mac Agent passe hors ligne malgré la suppression d’un Workspace, ne videz pas toute la machine : séparez d’abord les espaces Jenkins, les données Xcode, les composants du simulateur, les archives et les caches, puis ne supprimez que ce qui est reconstruisible et non utilisé.

Le nettoyage du disque d’un Jenkins Mac Agent est adapté lorsque l’agent doit rester disponible pour les builds iOS, la signature, les tests de simulateur ou des pipelines audio, vidéo et design nécessitant des outils Apple spécifiques. Si l’espace libre diminue encore après une opération contrôlée, réduisez la concurrence, isolez la signature et préparez l’ajout d’un Mac distant.

Vous êtes concerné si vous administrez les alertes disque et la remise en service des agents. Vous pilotez peut-être aussi la performance CI/CD, les politiques de cache ou le dimensionnement de plusieurs Mac de compilation. Enfin, ce guide vous aide à décider si le problème vient d’une croissance incontrôlée, d’une concurrence excessive ou d’un stockage devenu trop limité.

Commencez par prouver où le disque disparaît

Un agent signalé comme saturé ne signifie pas automatiquement que le dernier Workspace est responsable. Dans un cas courant, un administrateur supprime le répertoire du projet le plus volumineux, mais l’espace disponible reste presque inchangé. La cause se trouve alors dans un autre emplacement : données utilisateur, archives Xcode, simulateurs, fichiers temporaires ou copies conservées par un système de publication.

Jenkins sait surveiller l’espace du système de fichiers distant et certains répertoires temporaires d’un nœud. Cette capacité est documentée dans le guide officiel de gestion des nœuds Jenkins, mais elle ne remplace pas une attribution précise de la consommation.

Commencez par relever séparément :

  • le chemin Remote FS configuré pour l’agent Jenkins ;
  • les répertoires de Workspace réellement utilisés par les jobs ;
  • la bibliothèque de l’utilisateur qui exécute les builds ;
  • les dossiers temporaires et les fichiers de logs ;
  • les archives Xcode, les fichiers dSYM et les éléments associés aux publications ;
  • les caches de Swift Package Manager, CocoaPods, Homebrew, Git LFS et les outils propres au projet ;
  • les volumes ou stockages externes qui contiennent une seconde copie des artefacts.

Pour une première lecture, utilisez uniquement des commandes de diagnostic non destructives :

df -h
du -sh "$HOME"/* 2>/dev/null
du -sh "$WORKSPACE"/* 2>/dev/null
find "$HOME" -type f -mtime +30 -print

Ces commandes ne prouvent pas qu’un fichier peut être supprimé. Elles donnent une taille logique, une date de modification et une zone à examiner. APFS peut aussi présenter une différence entre taille logique, espace réellement alloué et espace récupérable après la suppression de fichiers protégés par des instantanés ou encore ouverts par un processus. Ne prenez donc pas la classification du Finder comme unique critère.

Conservez, pour chaque zone, trois observations : volume occupé, vitesse de croissance et dernière utilisation connue. Un fichier volumineux mais stable et nécessaire à la publication n’a pas le même profil qu’un cache qui augmente à chaque build.

Séparez les Workspaces actifs des restes reconstruisibles

Pipeline attribue automatiquement un Workspace à une tâche, et les builds concurrents peuvent provoquer la création de répertoires portant un suffixe. Le comportement est décrit dans la documentation officielle de Pipeline et dans la syntaxe des Workspaces Jenkins. Une branche supprimée dans le dépôt ne garantit donc pas que son ancien répertoire local a disparu.

Inspectez quatre catégories avant toute suppression :

  • le Workspace du build en cours ;
  • les Workspaces associés à des branches ou jobs encore planifiés ;
  • les répertoires générés par une exécution concurrente ;
  • les dossiers orphelins dont aucun job ne revendique plus l’usage.

Le chemin configuré dans Jenkins doit être vérifié avant le chemin supposé. Un job peut employer un Workspace personnalisé, un répertoire temporaire ou une convention différente de celle des autres pipelines. Consultez également les journaux de nettoyage : l’absence d’un message de suppression ne prouve pas que le nettoyage a échoué, mais elle justifie une vérification de l’état réel du disque.

Un Workspace Jenkins peut-il être supprimé automatiquement à la fin d’un build ?

Oui, mais uniquement si le contenu n’est pas utilisé comme cache indispensable ou comme preuve de diagnostic. Le plugin officiel Workspace Cleanup fournit notamment l’étape cleanWs. Vous pouvez l’exécuter dans une section post, avec des exclusions limitées et documentées, plutôt que d’ajouter une suppression globale dans le script du job.

Une politique raisonnable distingue :

  • un nettoyage après chaque build pour les fichiers temporaires clairement reconstruisibles ;
  • une conservation courte pour les éléments utiles à l’analyse d’un échec ;
  • une conservation plus longue pour les artefacts transférés vers le stockage de référence ;
  • une maintenance contrôlée pour les anciens Workspaces dont l’usage est confirmé comme nul.

Ne lancez jamais un rm -rf généralisé sur le Remote FS pendant que l’agent accepte encore des tâches. Un build peut avoir ouvert un fichier, un processus de test peut utiliser un simulateur et une étape de signature peut dépendre d’un chemin situé hors du répertoire visible dans la console.

Classez les données Xcode selon leur valeur

Les fichiers produits par Xcode ne forment pas un seul cache. Leur suppression n’a pas le même coût ni le même risque.

DerivedData est-il généralement reconstruisible ?

Dans la plupart des pipelines, DerivedData peut être recréé à partir du code, des dépendances et de la configuration Xcode. Sa suppression peut toutefois imposer une compilation complète au prochain build. Vous devez donc mesurer le temps de reconstruction dans votre propre pipeline avant d’en faire une règle de nettoyage agressive. Une branche qui compile rarement, un projet audio lourd ou une application vidéo avec de nombreux modules peut subir un coût différent d’un petit projet.

Les données de simulateur peuvent-elles être nettoyées sans précaution ?

Pas tant que vous n’avez pas séparé les données d’exécution des runtimes installés. Un dossier de simulateur peut contenir des appareils, des résultats de tests ou des données utilisées par un diagnostic en cours. Les runtimes et composants de plateforme sont encore une autre catégorie : leur réinstallation dépend de l’accès réseau, des autorisations et de la version Xcode disponible. Apple documente le téléchargement et l’installation de composants Xcode supplémentaires.

Traitez donc les éléments dans cet ordre logique :

  • DerivedData : candidat au nettoyage si le build peut le reconstruire ;
  • données temporaires de simulateur : à supprimer seulement après vérification des jobs actifs ;
  • appareils et résultats de test : à conserver si une enquête qualité est ouverte ;
  • runtimes et plateformes : à conserver lorsque leur restauration est lente, réglementée ou dépend d’un réseau restreint ;
  • archives et dSYM : à protéger jusqu’à validation de la politique de publication et de support.

Les archives ne sont pas de simples caches. Elles peuvent être nécessaires pour symboliser un crash, reproduire une version publiée ou répondre à une demande de support. La documentation Apple sur les informations de débogage et les fichiers dSYM explique leur rôle dans l’analyse des incidents.

Rendez la responsabilité des caches explicite

Un cache devient dangereux lorsqu’aucune équipe ne sait pourquoi il existe, qui peut le reconstruire ou quelle copie fait foi. Sur un Mac Agent, vous pouvez trouver la même dépendance dans le Workspace, le répertoire utilisateur et un stockage d’artefacts. Nettoyer une seule copie ne résout alors pas le problème de capacité ; supprimer la mauvaise copie allonge seulement le prochain build.

Pour chaque famille de données, consignez quatre propriétés :

  • propriétaire : équipe mobile, plateforme, publication ou sécurité ;
  • reconstructibilité : complète, partielle ou non garantie ;
  • portée du partage : un job, une branche, plusieurs projets ou tous les agents ;
  • déclencheur de nettoyage : âge, volume, fin de release, changement de version ou intervention validée.

Appliquez cette grille aux caches Swift Package Manager, CocoaPods, Homebrew et Git LFS. Ajoutez les caches propres aux outils de design, d’audio ou de vidéo si vos pipelines génèrent des ressources lourdes. La question n’est pas de tout conserver ou de tout supprimer, mais d’éviter une duplication sans responsable.

Examinez aussi les trois emplacements fonctionnels : Jenkins Controller, Mac Agent et stockage d’artefacts. Un artefact conservé sur l’agent et dans le stockage central peut être nécessaire pendant une période courte, mais cette duplication doit être volontaire. Une suppression locale ne résout pas une politique de rétention excessive côté serveur.

Utilisez cette grille avant de choisir une action

Une décision fiable doit relier la cause observée à une action limitée. Cochez chaque condition qui correspond à votre agent, puis arrêtez-vous à la première branche applicable :

  • [ ] Si la consommation provient surtout de Workspaces orphelins et de caches reconstruisibles, choisissez une politique de cycle de vie Jenkins et un nettoyage contrôlé.
  • [ ] Si les builds concurrents créent plusieurs copies temporaires, réduisez la concurrence ou séparez les jobs avant d’augmenter le stockage.
  • [ ] Si les archives, dSYM et runtimes nécessaires occupent durablement l’agent, isolez le nœud de signature ou de publication du nœud de compilation ordinaire.
  • [ ] Si le nettoyage devient plus fréquent et allonge la fenêtre de maintenance, ajoutez une capacité fixe ou un Mac distant plutôt que de repousser sans cesse le seuil d’alerte.
  • [ ] Si le nœud ne peut pas restaurer ses composants dans votre délai de reprise, conservez les éléments nécessaires et prévoyez un agent supplémentaire.
  • [ ] Si un agent porte simultanément compilation, tests, signature et publication, répartissez ces responsabilités avant de conclure que le disque est sous-dimensionné.
  • [ ] Si aucune source dominante n’est identifiée, retardez la suppression et collectez d’abord l’évolution quotidienne, les processus ouverts et les chemins réellement utilisés.

Cette grille est le principal outil de décision du runbook. Elle évite de confondre une correction de rétention avec une extension d’infrastructure. Elle empêche également de traiter un nœud de signature comme un simple espace de compilation.

Isolez les opérations qui peuvent casser la publication

Une erreur de nettoyage peut produire un incident plus grave que l’alerte disque. Les risques principaux sont les suivants :

  • suppression d’un Workspace encore utilisé par un build concurrent ;
  • effacement d’un certificat, d’un profil ou d’un élément de Keychain ;
  • disparition d’une archive ou d’un dSYM requis pour une analyse ;
  • suppression d’un runtime indispensable à une matrice de tests ;
  • destruction de logs avant la qualification d’un échec ;
  • suppression d’un artefact qui n’a pas encore été transféré.

Les identifiants de signature ne doivent jamais être inclus dans un script générique de nettoyage. Ils appartiennent à un périmètre de sécurité séparé, avec une procédure de restauration testée. La distribution d’une application suit également ses propres contraintes ; consultez la documentation Apple sur la distribution pour les tests et les versions avant de modifier les archives de publication.

Avant une intervention :

  • retirez temporairement l’agent de la file d’exécution ou bloquez l’acceptation de nouveaux jobs ;
  • vérifiez les processus qui utilisent le répertoire ciblé ;
  • exportez la liste des chemins concernés et leur propriétaire ;
  • identifiez la source de restauration des composants supprimables ;
  • définissez une fenêtre de retour arrière ;
  • conservez les journaux de l’opération.

Après l’opération, ne vous contentez pas de constater l’espace libéré. Exécutez une séquence d’acceptation : récupération du code, restauration des dépendances, build ordinaire, tests, signature et production d’un artefact. Vérifiez ensuite le redémarrage de l’agent et le retour des métriques de capacité. Une publication réussie et une reprise correcte après redémarrage valent davantage qu’un compteur de gigaoctets libérés.

Choisissez entre nettoyage, limitation et extension

Un Mac de construction qui se remplit à répétition souffre-t-il d’une mauvaise politique ou d’un manque de capacité ?

Utilisez les données de plusieurs cycles de construction pour répondre. Un nettoyage fréquent mais efficace indique souvent une rétention mal réglée. Une croissance régulière malgré un nettoyage documenté peut révéler une concurrence trop élevée, des runtimes multiples ou des artefacts mal externalisés. Si la capacité baisse surtout pendant les pics de build, le problème relève davantage du dimensionnement.

Les seuils d’alerte, de refus de nouveaux jobs et d’intervention humaine doivent être calculés à partir du pic réel d’un build, de l’espace requis pour restaurer les composants et de la marge de reprise imposée par votre entreprise. Ne recopiez pas un seuil générique trouvé dans un script. Suivez plutôt la croissance quotidienne, la fréquence des nettoyages, le temps de reconstruction des caches, la longueur de la file Jenkins et les périodes où l’agent est hors ligne. Les règles de conservation des builds multibranches peuvent compléter cette analyse côté historique Jenkins.

La documentation générale de gestion Jenkins doit également être consultée lorsque la maintenance modifie l’état du nœud, ses exécutors ou sa capacité à accepter de nouvelles tâches. Le nettoyage ne doit pas contourner le contrôle opérationnel de Jenkins.

Validez un scénario de Mac distant sans masquer le problème

Un Mac distant ne remplace pas une politique de rétention. Il devient pertinent lorsque vos mesures démontrent qu’un seul agent concentre trop de fonctions ou que l’augmentation de capacité locale ne suffit plus à absorber les pics.

L’intérêt est concret pour une équipe qui doit réserver un nœud stable à la signature, fournir un environnement macOS temporaire à des développeurs ou absorber une campagne de tests sans acheter immédiatement une machine supplémentaire. Vous pouvez examiner les possibilités de Mac distant proposé par MACCOME et comparer un environnement dédié selon la localisation souhaitée, par exemple avec une offre Mac mini cloud.

Avant toute décision, demandez à votre équipe de renseigner une fiche par agent :

  • croissance du stockage entre deux cycles de référence ;
  • espace consommé par Workspace, Xcode, dépendances et archives ;
  • nombre de jobs simultanés ;
  • durée de reconstruction après nettoyage ;
  • fréquence des mises hors ligne ;
  • temps nécessaire pour restaurer un environnement ;
  • rôle du nœud : compilation, test, signature ou publication.

Cette fiche permet de distinguer une extension ponctuelle d’une architecture durable. Elle évite aussi de déplacer silencieusement les doublons vers un nouvel agent.

Le nettoyage local est-il encore préférable à la location ?

Votre solution actuelle peut rester adaptée si la charge est stable, si l’équipe maîtrise le stockage et si un Mac physique est nécessaire pour des périphériques ou des opérations locales. Elle devient moins confortable lorsque vous devez immobiliser du budget dans du matériel sous-utilisé, gérer les remplacements, maintenir plusieurs environnements Xcode et absorber une hausse temporaire des builds.

Le partage d’une seule machine crée également un risque de concurrence entre compilation, tests et signature. À l’inverse, ajouter un nœud physique demande de l’achat, de l’installation, de la supervision et une capacité disponible même lorsque la demande baisse. Une location de Mac distant auprès de MACCOME peut offrir une voie plus souple pour un pilote, une campagne de release ou un nœud Jenkins supplémentaire : vous testez la charge avec des données réelles avant de figer un investissement matériel.

La décision reste défavorable à la location si vous avez besoin d’un périphérique physique spécifique, d’une charge permanente et prévisible ou d’un contrôle matériel complet. Dans les autres cas, lorsque les alertes disque et les files d’attente montrent un manque ponctuel ou une séparation nécessaire entre compilation et signature, ajouter un Mac distant est souvent plus propre que supprimer indéfiniment des données utiles.