Le premier chiffre à relever sur un agent Mac Jenkins est l’espace réellement disponible au moment de l’alerte, et non la seule taille totale du disque. Jenkins propose une étape dédiée pour nettoyer un espace de travail, mais cela ne signifie pas que tous les répertoires volumineux peuvent être supprimés sans conséquence (documentation de l’étape de nettoyage Jenkins). Identifiez d’abord si l’espace est occupé par les espaces de travail, les composants Xcode ou les artefacts ; nettoyez uniquement la catégorie vérifiée, puis réévaluez le nœud si les alertes reviennent.
Cet article s’adresse aux responsables IT qui doivent déterminer si les alertes de stockage fragilisent leurs compilations Mac. Il est aussi destiné aux équipes plateforme qui gèrent les agents Jenkins, les espaces de travail et les installations Xcode. Les responsables techniques et de l’efficacité développeur y trouveront des critères pour choisir entre une meilleure politique de nettoyage et une évolution de l’infrastructure.
Distinguer une alerte de disque d’un échec de compilation
Une alerte de stockage, une erreur d’écriture et une compilation en échec sont trois observations différentes. La première signale une condition de capacité ; la deuxième peut apparaître lorsqu’un processus ne peut pas créer ou modifier un fichier ; la troisième peut également venir d’une dépendance, d’un problème réseau, d’une erreur de signature ou d’un outil indisponible. Traitez-les comme des indices à corréler, pas comme des diagnostics équivalents.
Commencez par relever, pour le même créneau temporel, l’espace disponible sur le volume concerné, la tâche Jenkins impliquée, son étape d’échec et les messages d’erreur associés. Si le volume est encore disponible mais que la tâche échoue lors de la récupération d’une dépendance, par exemple, l’espace disque n’est pas confirmé comme cause. À l’inverse, un message explicite d’échec d’écriture accompagné d’une baisse persistante de l’espace disponible renforce cette hypothèse.
La vue de stockage de macOS peut aider à repérer les catégories générales d’occupation ; Apple décrit les options de consultation et de gestion dans son guide sur les réglages de stockage du Mac. Cette vue ne remplace toutefois pas l’inventaire des répertoires utilisés par votre agent Jenkins : les résultats des tâches et les règles de conservation sont propres à votre environnement.
| Observation | Ce qu’elle permet de conclure | Vérification à effectuer avant d’agir |
|---|---|---|
| Alerte de disque sans échec de tâche | Le seuil d’alerte est atteint, mais une panne de compilation n’est pas démontrée. | Consigner l’espace disponible et examiner la tendance. |
| Échec d’écriture pendant une tâche | Le manque d’espace est plausible, sans être automatiquement prouvé. | Corréler l’erreur avec le volume et l’heure de l’échec. |
| Compilation en échec sans erreur de stockage | La cause peut se trouver dans la chaîne d’outils, le réseau ou la tâche elle-même. | Lire les premières erreurs utiles et vérifier les dépendances. |
| Reprise normale après nettoyage | La catégorie retirée a pu contribuer au problème. | Confirmer le résultat avec une compilation représentative, pas uniquement avec la disparition de l’alerte. |
**À retenir :** ne lancez pas un nettoyage général en réaction à une compilation en échec. Préservez d’abord les journaux de la tâche et notez l’état du volume ; sinon, vous risquez de retirer des éléments nécessaires pour reproduire le problème.
Localiser les répertoires responsables avant tout nettoyage
La question « quels dossiers sont volumineux ? » ne suffit pas à décider quoi supprimer. Vous devez aussi savoir à quel processus ils appartiennent, s’ils sont régénérables et si leur contenu est requis pour une publication ou une investigation. Faites un inventaire par catégorie et comparez-le avec les tâches qui tournent sur le même agent.
Première étape : examiner les espaces de travail Jenkins
Vérifiez si les espaces de travail sont conservés après la réussite, l’échec ou l’interruption d’une tâche. Le comportement dépend de la définition du Pipeline et de ses étapes : ne partez pas du principe que le répertoire sera supprimé automatiquement. La documentation Jenkins présente le fonctionnement des Pipelines et la syntaxe des actions de fin dans la référence du Pipeline.
Inspectez également les espaces de travail créés par des exécutions simultanées. Une tâche qui utilise plusieurs répertoires ou des noms de travail différents peut laisser davantage de données que prévu. Comparez l’occupation avec les états de tâche : une exécution interrompue peut conserver des éléments utiles pour comprendre l’incident. Si vous retirez ces données avant d’avoir sauvegardé les journaux nécessaires, vous réduisez vos possibilités de diagnostic.
Une politique de nettoyage doit donc préciser les situations visées, les chemins concernés et les exceptions. Jenkins documente les options de l’étape cleanWs dans sa référence du nettoyage des espaces de travail. Adaptez ces options à votre Pipeline et testez-les sur une tâche représentative ; ne copiez pas une règle d’exclusion sans vérifier les fichiers réellement produits par vos compilations.
Deuxième étape : inventorier Xcode et les environnements de simulateur
Distinguez l’application Xcode des composants facultatifs, des plateformes prises en charge et des environnements d’exécution de Simulator. Les projets ne requièrent pas tous les mêmes versions d’outils ou de systèmes : avant de retirer un élément, relevez les versions sélectionnées par vos tâches de compilation et de test.
Apple documente la gestion des composants supplémentaires de Xcode, y compris les moyens de supprimer des éléments qui ne sont plus utilisés, dans sa documentation sur le téléchargement et l’installation des composants Xcode. Pour les environnements de simulateur, consultez également les indications Apple sur l’ajout et la gestion de simulateurs.
Cela répond à la question de savoir si un Xcode Simulator runtime peut être retiré : oui, si aucun projet ou test actif ne dépend de cet environnement, et si la suppression est effectuée par un mécanisme de gestion prévu à cet effet. Évitez de transformer un chemin de répertoire observé sur un agent en règle de suppression applicable à toutes les machines. Après le retrait, vérifiez que les destinations de test encore nécessaires restent disponibles.
Troisième étape : séparer artefacts, journaux et fichiers temporaires
Recherchez les archives de publication, les symboles, les rapports de test, les journaux et les sorties temporaires. Leur présence n’a pas la même valeur opérationnelle : certains fichiers sont reproductibles, tandis que d’autres peuvent être exigés pour une livraison, un audit ou l’analyse d’une régression. Associez à chaque catégorie un propriétaire, une durée de conservation et un emplacement de sauvegarde ou d’archivage lorsqu’il est requis.
Pour les compilations de publication, la validation ne doit pas s’arrêter à la présence d’un fichier d’archive. Apple décrit des vérifications destinées aux compilations de publication dans son guide sur les tests d’une version destinée à la distribution. Utilisez cette référence pour intégrer la validation de la sortie à votre procédure, tout en définissant la conservation selon les contraintes de votre équipe.
| Catégorie | Décision de nettoyage | Risque principal |
|---|---|---|
| Espace de travail d’une tâche terminée | Nettoyer selon le résultat, les exclusions et les besoins de diagnostic définis. | Perdre des fichiers utiles pour reproduire un échec. |
| Composant Xcode ou Simulator inutilisé | Retirer par les mécanismes de gestion Xcode après vérification des dépendances. | Rendre indisponible une destination de compilation ou de test. |
| Archive ou symboles nécessaires à une livraison | Conserver ou archiver conformément aux règles internes. | Perdre des éléments requis pour distribuer ou diagnostiquer l’application. |
| Rapports, journaux et sorties temporaires | Définir une politique par catégorie et selon leur usage réel. | Supprimer une preuve d’incident ou conserver des fichiers sans propriétaire. |
Appliquer un nettoyage réversible et vérifier le retour à la normale
Procédez sur une tâche et une catégorie à la fois. Si plusieurs types de données sont supprimés simultanément, vous ne saurez pas quelle action a libéré l’espace ni laquelle a affecté la compilation. Conservez les informations nécessaires pour revenir à l’état précédent ou reproduire les conditions de l’échec.
- [ ] Relever l’espace disponible, le volume concerné, l’heure et l’identifiant de la tâche en échec.
- [ ] Conserver les journaux de la tâche et les fichiers requis pour l’analyse, la publication ou l’audit.
- [ ] Mesurer séparément l’espace occupé par les espaces de travail, les composants Xcode et les artefacts.
- [ ] Identifier les versions de Xcode et les environnements de simulateur effectivement utilisés par vos projets.
- [ ] Définir une règle limitée à la catégorie confirmée, avec des exclusions explicites et une procédure de retour arrière.
- [ ] Tester le nettoyage sur une tâche représentative, puis exécuter une compilation et les tests concernés.
- [ ] Comparer l’espace disponible, le résultat des tâches et les erreurs avant et après l’intervention.
- [ ] Documenter la règle retenue, son responsable et les éléments qui doivent rester conservés.
**Point de contrôle :** si le nettoyage empêche une tâche de retrouver ses dépendances ou supprime les preuves d’un échec, revenez à la règle précédente et restreignez son périmètre avant de la déployer sur d’autres agents.
Choisir entre une politique de nettoyage et une capacité Mac différente
Lorsque le disque est de nouveau presque plein après une intervention, ne concluez pas immédiatement qu’il faut ajouter un nœud. Constituez d’abord une série de relevés représentative de votre activité : catégories qui croissent, tâches simultanées, fréquence des alertes, éléments à conserver et incidents de compilation associés. La période pertinente dépend de votre rythme de publication et de la variabilité de vos tâches ; aucun seuil universel ne permet de trancher sans ces données.
Le tableau ci-dessous fournit une grille de décision qualitative. Elle ne prédit ni un gain de capacité ni un coût : ces résultats dépendent de vos tâches, de la machine et des modalités réellement disponibles.
| Situation observée dans vos relevés | Orientation à tester | Point de vigilance |
|---|---|---|
| Les espaces de travail s’accumulent après des tâches terminées. | Corriger les règles de nettoyage et contrôler les exceptions. | Garder les fichiers qui expliquent les échecs ou servent aux livraisons. |
| Des composants Xcode ne sont plus requis par les projets actifs. | Retirer les éléments inutilisés par les outils Xcode, puis valider les tests. | Vérifier les versions de système et destinations de compilation encore nécessaires. |
| Les archives et rapports doivent être conservés, mais restent sur le volume de compilation. | Séparer la conservation des livrables de l’espace de travail du nœud. | S’assurer que les copies archivées sont accessibles et conformes à vos règles. |
| Les alertes reviennent malgré un nettoyage contrôlé et des tâches terminent en manque d’espace. | Évaluer une modification de la gestion des tâches, de la capacité ou du mode d’hébergement. | Comparer les journaux et besoins réels ; ne pas présumer qu’un nouveau nœud résoudra une autre cause. |
La location d’un Mac distant mérite d’être évaluée lorsque vous avez besoin d’un environnement Mac supplémentaire ou ajustable sans acheter immédiatement une machine dédiée. Elle ne convient pas automatiquement à tous les usages : une charge permanente et prévisible peut justifier une machine détenue et administrée en interne, tandis qu’un besoin d’interface physique ou de contrôle local peut rendre le distant inadapté. Avant de choisir, vérifiez les configurations réellement proposées, la durée de location, le mode de livraison et les exigences d’accès. Vous pouvez examiner les informations publiées par MACGPU sur ses solutions Mac et revenir à la présentation MACGPU pour confronter cette option à vos contraintes, sans présumer d’un gain de disque ou de coût.
FAQ : résoudre les alertes de stockage de Jenkins
Quels répertoires examiner en premier sur un agent Mac Jenkins ?
Commencez par relever l’espace disponible sur les volumes concernés, puis mesurez séparément les espaces de travail Jenkins, les données liées à Xcode et les répertoires de sortie des compilations. Comparez ces relevés aux tâches qui ont échoué ou tourné simultanément. Les chemins précis et leur importance dépendent de votre configuration : ne supprimez pas un répertoire uniquement parce qu’il est volumineux.
Peut-on supprimer un environnement d’exécution Simulator de Xcode sans risque ?
Vous pouvez retirer un environnement de simulateur qui n’est plus requis, mais vérifiez d’abord les versions de système ciblées par vos projets et vos tests actifs. Utilisez la gestion des composants proposée par Xcode pour identifier les éléments concernés. Après la suppression, exécutez les tests utilisant Simulator ; ne traitez pas la suppression manuelle de répertoires système comme une méthode universelle.
Le nettoyage d’un espace de travail Jenkins peut-il supprimer des fichiers utiles ?
Oui. Selon les tâches et leur configuration, un espace de travail peut contenir des modifications, des journaux ou des fichiers nécessaires à l’analyse d’un échec. Définissez les règles de nettoyage selon le résultat de la compilation et vos obligations de conservation. Avant de les généraliser, vérifiez qu’un échec reste diagnostiquable et que les livrables à conserver sont archivés ailleurs.
Quand faut-il revoir la capacité d’un nœud Mac CI ?
Envisagez cette décision lorsque des relevés représentatifs montrent que les mêmes catégories d’occupation reviennent malgré un nettoyage ciblé, ou que la conservation requise des artefacts entre en conflit avec les tâches prévues. Tenez compte des compilations simultanées et des interruptions observées. Une alerte isolée ne suffit pas : comparez les journaux, l’espace disponible et les échecs sur une période adaptée à votre activité.
Si vos relevés montrent que les espaces de travail sont mal gérés, corrigez d’abord les règles ; si les composants ou les artefacts sont en cause, traitez leur cycle de vie sans effacer les éléments requis. Lorsque la charge et les obligations de conservation dépassent durablement ce que votre organisation peut gérer sur les nœuds actuels, comparez l’exploitation de vos Mac internes à une capacité distante. L’achat implique notamment de financer et d’entretenir le matériel, de gérer les périodes de sous-utilisation et d’organiser les remplacements ; la location déplace une partie de ces contraintes, mais nécessite de vérifier l’accès, la disponibilité et l’adéquation du service à vos tâches. Si vous avez besoin d’un environnement Mac temporaire ou d’un nœud supplémentaire pour évaluer cette option, consultez les offres MACGPU après avoir établi vos critères, sans remplacer votre diagnostic par une promesse de capacité ou d’économie.