Que faire en cas d’espace disque insuffisant sur un CI Mac distant ? Guide de diagnostic 2026

Dès la prochaine alerte, identifiez d’abord si l’espace est occupé par DerivedData, des simulateurs, des archives ou le répertoire de travail ; ne supprimez que les données que vous avez vérifiées comme recréables. Cette méthode convient aux compilations et aux archives qui échouent comme aux Runner macOS persistants dont le stockage diminue d’une tâche à l’autre.

Pour qui : développeurs iOS et macOS confrontés à une compilation ou une archive en échec sur un Mac distant.
Ingénieurs CI qui entretiennent un Runner autogéré et doivent éviter l’accumulation entre les tâches.
Équipes réduites qui doivent choisir entre nettoyer, modifier leur flux de travail ou augmenter la capacité de l’hôte.

Diagnostic immédiat des symptômes

Un message de stockage insuffisant est un indice, pas un diagnostic complet. Une tâche peut échouer pendant l’écriture des produits de compilation, au moment de créer une archive, ou parce qu’un processus n’arrive plus à enregistrer ses journaux. Une alerte de macOS, elle, peut signaler un volume presque plein sans identifier le fichier responsable. La première action est donc de conserver le journal complet et de relever l’étape exacte où le problème apparaît.

Notez le répertoire de travail, le volume utilisé par la tâche et l’état du stockage avant tout nettoyage. Sur l’hôte concerné, df -h / affiche l’espace disponible pour le volume racine ; du -sh peut aider à comparer la taille de répertoires identifiés. Les résultats dépendent du système de fichiers, des autorisations et du chemin interrogé : ils ne remplacent pas l’examen des fichiers de la tâche. Pour vérifier le stockage depuis l’interface macOS, suivez les indications d’Apple pour consulter l’espace utilisé sur un Mac.

Comparez une tâche en échec à une exécution réussie, si vous en avez une, et cherchez ce qui a changé : projet, cible, dépendances, volume utilisé ou conservation des sorties. Si le problème ne survient qu’après plusieurs tâches, examinez les résidus persistants. Si l’espace manque dès le début d’une tâche, contrôlez d’abord la capacité réellement disponible et les données préexistantes. Ne déduisez pas la cause d’un seul libellé d’erreur.

Localisation des répertoires réellement occupés

Les catégories affichées par macOS donnent une vue d’ensemble ; elles ne constituent pas une preuve qu’un dossier précis est supprimable. Mesurez les répertoires liés au travail du Runner, aux projets, aux données Xcode et aux journaux. Si vous ne pouvez pas lire un répertoire avec le compte utilisé, faites vérifier les autorisations au lieu d’interpréter une mesure incomplète comme une absence de données.

Xcode sépare notamment les données de développement des archives de projets. Les emplacements habituels documentés sont ~/Library/Developer/Xcode/DerivedData et ~/Library/Developer/Xcode/Archives. Les notes de version d’Apple décrivent l’emplacement des fichiers de compilation ; la documentation technique d’Apple sur les problèmes d’archivage aide à distinguer le diagnostic d’une archive de celui d’une compilation. Vérifiez toutefois le chemin réellement configuré sur votre hôte : un flux de travail peut écrire ailleurs.

Dans une situation de production, ajoutez à votre journal de tâche l’espace disponible au début et à la fin, ainsi que le chemin du répertoire de travail. Une différence entre ces mesures ne révèle pas à elle seule le dossier responsable, mais elle permet de repérer si la consommation apparaît pendant une tâche ou s’accumule entre deux exécutions. Pour examiner un dossier dont vous ne connaissez pas le contenu, listez-le et confrontez les fichiers à leur usage avant d’agir.

La présence de données dans un dossier de développement ne signifie pas qu’elles sont toutes temporaires. Des journaux peuvent être nécessaires pour comprendre un échec ; des sorties peuvent être attendues par une étape ultérieure ; certains fichiers peuvent être partagés entre tâches. À l’inverse, une ancienne sortie de compilation peut être recréable, mais uniquement si le pipeline sait effectivement la générer à nouveau. Établissez cette distinction à partir de votre configuration et de vos besoins de conservation.

Données Xcode et archives après une compilation

DerivedData contient des données associées au développement du projet, dont des éléments de compilation et des journaux. Les archives sont conservées séparément et peuvent être nécessaires à la distribution, à l’audit ou à une reprise de livraison. Supprimer tout le répertoire Xcode parce qu’une compilation manque d’espace confond ces usages et peut effacer des éléments utiles à l’équipe.

Avant une suppression, identifiez l’archive concernée, son utilité et l’endroit où une copie est conservée. Apple décrit les difficultés courantes d’archivage dans sa note technique sur la résolution des problèmes d’archives Xcode. Elle ne justifie pas de supprimer les archives comme remède général à un manque d’espace : le choix dépend de ce que vous devez livrer et conserver.

Si DerivedData semble être le principal occupant, commencez par vérifier si les projets qu’il contient sont encore utilisés et si une reconstruction propre est acceptable. N’effacez pas simultanément les données de projet, les archives et les journaux : en cas d’échec ultérieur, vous ne sauriez plus quelle action a changé le résultat. Une suppression ciblée, suivie d’une compilation représentative, vous donne une meilleure base pour décider si le nettoyage peut devenir une règle d’exploitation.

Pour vérifier le comportement attendu, utilisez les outils documentés par Apple plutôt qu’une suppression manuelle d’un dossier dont la fonction n’est pas claire. La documentation Apple sur la construction et l’exécution d’une app fournit le contexte du flux de compilation et de lancement. Le point à contrôler reste votre projet : la sélection de Xcode, la cible, les sorties attendues et les étapes qui réutilisent les fichiers.

Simulateurs et composants de développement

Un test avec simulateur peut laisser plusieurs catégories de données : composants nécessaires à l’exécution, données associées aux appareils simulés et produits générés par le projet. Examinez ces éléments séparément. Le fait qu’un simulateur ne soit pas lancé au moment de l’inspection ne démontre pas qu’il est inutilisé par le prochain lot de tests ou par une autre version de Xcode.

Dans Xcode, commencez par repérer les simulateurs et composants installés, puis comparez-les aux destinations réellement déclarées dans vos tâches. Apple documente l’ajout de simulateurs et le téléchargement de composants Xcode. Ces références aident à comprendre que les composants installés servent aux environnements de développement ; elles ne permettent pas de conclure qu’un composant précis peut être supprimé sans conséquence sur votre configuration.

Procédez par élément : relevez ce qui est installé, retirez uniquement ce dont l’équipe a confirmé qu’il n’est plus requis, puis relancez les tests sur la destination attendue. Enregistrez l’espace disponible avant et après chaque changement. Cette façon de faire n’empêche pas une erreur, mais elle permet d’identifier l’action qui l’a provoquée et de revenir sur une décision trop large.

Résidus des Runner autogérés

Un Runner hébergé par GitHub et un Runner autogéré ne confient pas la même responsabilité de stockage à votre équipe. La documentation de GitHub précise que le choix du Runner dépend du type d’exécution configuré pour la tâche : consultez les options de Runner pour un travail avant d’attribuer un résidu au bon environnement.

Sur un hôte autogéré persistant, les répertoires de travail, caches et outils peuvent subsister d’une exécution à l’autre, selon la configuration et le nettoyage du Runner. GitHub décrit les caractéristiques et la gestion des Runner autogérés. Vous devez donc décider vous-même quelles données conserver, combien de temps les journaux restent utiles et quelles sorties peuvent être recréées.

Ne traitez pas le répertoire de travail, le cache, les archives et les identifiants comme une seule catégorie. Un nettoyage trop large peut supprimer des sources nécessaires à une étape, effacer des preuves d’échec ou endommager une configuration d’accès. Si vos tâches s’exécutent dans des conteneurs personnalisés, examinez également leur cycle de vie : la documentation GitHub sur la personnalisation des conteneurs de Runner autogérés décrit les options à vérifier pour votre configuration.

Une politique raisonnable commence par la classification : ce qui est supprimable après validation d’une tâche, ce qui doit être conservé pour le diagnostic, ce qui est nécessaire à la livraison et ce qui relève des accès. N’automatisez la suppression qu’après avoir testé une exécution complète, y compris la récupération d’une archive ou d’un résultat conservé. Pour un environnement partagé, documentez le propriétaire de chaque catégorie plutôt que de laisser chaque projet imposer sa propre règle silencieuse.

Liste de contrôle et validation après nettoyage

Utilisez cette liste avant de transformer une opération ponctuelle en nettoyage automatique :

• [ ] Consigner le journal complet et l’étape exacte de l’échec.
• [ ] Vérifier l’espace disponible sur le volume utilisé par la tâche.
• [ ] Mesurer séparément le répertoire de travail, DerivedData, les archives, les simulateurs et les journaux pertinents.
• [ ] Confirmer le contenu et le propriétaire des données visées, ainsi que leur rôle dans les étapes suivantes.
• [ ] Conserver les éléments nécessaires au diagnostic, à la livraison ou à une obligation de rétention.
• [ ] Nettoyer une catégorie ciblée et noter l’espace disponible immédiatement après.
• [ ] Exécuter une compilation représentative, puis les tests ou l’archivage concernés.
• [ ] Vérifier que le résultat est sauvegardé et qu’une tâche ultérieure peut démarrer.
• [ ] Ajouter une mesure de stockage avant et après les tâches du Runner autogéré.
• [ ] Déclencher une alerte selon la capacité réellement requise par vos tâches, plutôt que d’adopter un seuil sans rapport avec votre charge.

La validation doit couvrir le chemin qui a réellement échoué. Si l’incident concernait une archive, une simple compilation réussie ne suffit pas : vérifiez aussi la création et la conservation de l’archive attendue. Si le problème venait d’un test sur simulateur, vérifiez la destination et l’état de test nécessaires à votre projet. Comparez les journaux et les mesures d’espace avant et après ; une amélioration momentanée n’exclut pas une accumulation qui reprendra lors des tâches suivantes.

Les solutions ont des compromis différents. Un nettoyage ciblé est rapide, mais demande une bonne connaissance des fichiers et ne règle pas un volume durablement trop petit. Une politique de rétention préserve mieux les éléments utiles, mais nécessite de décider ce qui doit être conservé et de contrôler son application. Une capacité supérieure laisse davantage de marge, mais ne remplace pas le suivi des résidus ni la suppression de données inutiles. Choisissez à partir de la consommation observée par vos propres tâches, pas d’une estimation présentée comme universelle.

FAQ de diagnostic

Les questions les plus fréquentes portent sur la sécurité d’une suppression et sur la preuve que le pipeline a repris. Pour une suppression de données de simulateur, appliquez la même règle que pour DerivedData : vérifiez d’abord l’usage, réalisez une modification ciblée, puis testez le flux réel. Il faut pouvoir distinguer la restauration d’un espace disponible de la réparation effective de la tâche.

Un Runner autogéré demande une attention supplémentaire parce que le même hôte peut servir à plusieurs projets. Avant d’automatiser un nettoyage, attribuez les dossiers à leurs propriétaires et séparez les données de cache des identifiants, des archives et des journaux. Si une tâche échoue après la modification, la comparaison de mesures et de journaux vous aidera à déterminer si le nettoyage a touché un élément requis.

Choix de la suite pour votre CI Mac

Si une mesure ciblée libère de l’espace et que la compilation, les tests et l’archivage représentatifs réussissent ensuite, conservez le nettoyage sous une forme documentée et contrôlée. Si le problème revient parce que les sorties, les environnements de test ou plusieurs projets partagent un hôte persistant, revoyez la rétention et l’isolation des tâches avant de simplement agrandir le volume.

Un Runner déjà disponible peut éviter de gérer un Mac supplémentaire, mais vous gardez la responsabilité des résidus, de la capacité et des accès lorsqu’il est autogéré. Un Mac local offre un contrôle direct, mais mobilise votre matériel et doit rester disponible pendant les tâches. Si la charge reste élevée et que la capacité de votre hôte actuel ne correspond plus aux besoins mesurés, examinez d’abord votre configuration d’environnement de développement Mac distant, puis comparez-la à une option matérielle telle que Mac mini disponible à Singapour. Pour des compilations temporaires, des tests ponctuels ou un environnement distant à essayer avant de revoir votre infrastructure, la location d’un Mac avec MangoVM peut être plus adaptée qu’un achat immédiat ; pour une charge soutenue exigeant un accès physique ou une disponibilité garantie par votre propre équipe, un hôte dédié que vous administrez peut rester le meilleur choix.

Questions fréquentes