Xcode No space left on device : correction du CI Mac distant 2026

Gel de l’incident et preuve initiale

Le premier réflexe ne doit pas être rm -rf, la suppression d’un dossier de travail complet ou la reconstruction du nœud. Une construction concurrente peut encore écrire des modules, un test peut produire des fichiers indispensables à son rapport et une archive peut représenter le seul artefact de livraison disponible.

Le développeur de permanence commence donc par interrompre le déclenchement de nouvelles tâches et par identifier les processus encore actifs. Le compte d’exécution, le chemin de travail et les paramètres de construction doivent être relevés avant toute modification. Les chemins ci-dessous sont volontairement génériques :

df -h /
df -i /
du -sh "/chemin/du/runner/*" 2>/dev/null
ps aux | grep -E 'xcodebuild|simctl|swift|clang' | grep -v grep

Ces commandes servent à distinguer un volume réellement plein d’un problème de répertoire, de fichiers supprimés mais encore ouverts ou de limites d’inœuds. La documentation d’Apple sur la gestion du stockage d’un Mac rappelle que l’espace visible par l’utilisateur ne suffit pas toujours à expliquer l’origine d’une saturation : l’analyse doit donc porter sur les catégories réellement écrites par le processus.

Conservez le premier message No space left on device, le nom de la tâche, le commit, les paramètres de compilation et l’état du volume. Si une seconde tentative a déjà été lancée, notez-la également : elle peut avoir modifié les volumes et rendre plus difficile l’attribution de l’espace consommé.

L’objectif de cette étape n’est pas encore de libérer le maximum d’espace. Il est de savoir si la panne provient d’un seul artefact abandonné, d’une croissance normale mal gouvernée ou d’une écriture concurrente qui continue malgré l’échec apparent.

Rétablissement du développeur de permanence

Le premier périmètre à traiter est l’espace de travail de la tâche interrompue. Examinez les clones répétés, les dossiers temporaires, les exports incomplets et les produits générés par des tâches déjà arrêtées. Le code source, les fichiers de configuration et les éléments nécessaires à une reproduction doivent rester intacts.

La règle de décision est stricte :

• un dossier produit par une tâche arrêtée, reproductible avec le même commit et sans valeur de livraison, peut être candidat au nettoyage ;
• un paquet exporté, un rapport de test, une archive ou un fichier demandé par une enquête reste conservé jusqu’à la fin de la remise ou du diagnostic ;
• un répertoire encore ouvert par xcodebuild, un outil de test ou un script de post-traitement n’est pas supprimé, même s’il semble volumineux ;
• un répertoire dont le propriétaire et l’origine sont inconnus est transmis au responsable du nœud avant intervention.

Après le nettoyage limité, reprenez exactement le même commit et les mêmes paramètres. Il faut vérifier la création du produit, l’écriture du rapport et la sortie complète du processus, pas seulement le code de retour de la commande. La référence Apple des outils en ligne de commande de Xcode permet de confronter les options utilisées par la chaîne avec celles réellement disponibles dans l’environnement actif.

Si l’espace libéré disparaît immédiatement, arrêtez les nouvelles relances. Une répétition automatique peut transformer un incident diagnostiquable en succession de constructions incomplètes. Le développeur transmet alors au responsable de la maintenance le relevé du volume, les processus observés et les catégories qui ont augmenté.

Pour les équipes qui alternent développement, audio, vidéo ou design avec des constructions Apple, il est particulièrement important de séparer les exports de travail des artefacts de CI. Un rendu temporaire ou un paquet de prévisualisation peut être régénérable, tandis qu’une archive destinée à une livraison peut constituer une preuve à conserver.

Gouvernance de DerivedData et des caches

Le responsable de la construction prend ensuite en charge DerivedData, les dépendances Swift Package, les caches de gestionnaires de paquets et les répertoires propres aux outils du projet. Le terme « cache » ne signifie pas automatiquement « déchet » : sa suppression peut déclencher une résolution, une recompilation ou un téléchargement qui consommera de nouveau de l’espace pendant la prochaine tâche.

Avant toute suppression, relevez :

• le chemin réellement défini par l’instance Xcode utilisée par le Runner ;
• le compte qui possède le répertoire et les permissions d’écriture ;
• la date de dernière modification et la tâche qui l’a produit ;
• la présence d’un processus qui lit ou écrit encore ce chemin ;
• la possibilité de reproduire le contenu avec le même verrouillage de dépendances.

Une commande d’inventaire peut aider à rapprocher taille et date, sans supposer que le chemin est identique sur tous les nœuds :

find "/chemin/du/cache" -mindepth 1 -maxdepth 1 -print0 |
  xargs -0 du -sh 2>/dev/null

Le chemin doit être obtenu à partir des paramètres de la chaîne et non copié depuis un ancien script. Les outils de ligne de commande documentés pour Xcode et l’aide locale de xcodebuild sont les références à vérifier lorsque la version de Xcode ou du système a changé.

La suppression d’un DerivedData abandonné peut être raisonnable lorsque toutes les constructions qui l’utilisent sont arrêtées et que le projet est reproductible. Elle ne l’est pas si une autre tâche partage ce chemin, si une analyse est en cours ou si le répertoire contient des éléments dont la conservation a été demandée. Après l’opération, exécutez une construction propre, puis une seconde construction destinée à confirmer le comportement de réutilisation. Une simple commande terminée avec succès ne prouve pas que la chaîne est redevenue stable.

La même prudence s’applique aux caches de dépendances. Le responsable doit documenter ce qui a été supprimé et ce qui reste conservé, puis transmettre au propriétaire du projet toute augmentation anormale constatée après la reconstruction.

Diagnostic d’iOS Simulator

Le responsable des tests doit séparer les runtimes installés, les appareils simulés et les données générées par les campagnes. Ces catégories n’ont pas le même rôle : un runtime peut être nécessaire à toute une matrice, un appareil simulé peut être abandonné, tandis que les données d’un test en cours peuvent être nécessaires à l’analyse d’un échec.

Commencez par identifier les composants et les appareils visibles dans l’environnement de test. Utilisez l’aide de l’outil présent sur le nœud plutôt qu’une commande copiée depuis un forum :

xcrun simctl help
xcrun simctl list

La documentation Apple relative à l’exécution d’une application sur des appareils simulés décrit le lien entre l’application, le runtime et l’appareil simulé. La documentation de gestion des appareils dans Device Hub doit être consultée avant de retirer un élément de la matrice.

La séquence sûre est la suivante : arrêter les tests, confirmer que le runtime à conserver est utilisé par une tâche active ou planifiée, repérer les appareils abandonnés, supprimer seulement ce qui est identifié comme inutile, puis démarrer de nouveau le runtime requis. Il faut ensuite exécuter un test représentatif, vérifier l’installation de l’application et contrôler la récupération après une déconnexion du Runner.

Ne modifiez pas directement des répertoires protégés du système pour gagner de l’espace. Une suppression non supportée peut laisser un appareil simulé dans un état incohérent, empêcher son démarrage ou produire une panne différente lors de la prochaine campagne. Les scripts communautaires peuvent servir à repérer un symptôme, mais ils ne constituent pas une garantie de sécurité ni une règle générale de suppression.

Protection des archives et de la signature

Le responsable de publication traite les archives, les paquets exportés, les symboles et les éléments d’envoi comme des actifs de livraison, et non comme de simples sorties de compilation. Une archive peut être nécessaire pour une reprise, une analyse de crash, une nouvelle exportation ou une justification de la version remise.

La procédure Apple d’archivage et de distribution permet de vérifier la chaîne attendue entre l’archive, l’export et la distribution. La documentation consacrée aux informations de débogage incluses dans une application aide également à déterminer quels éléments doivent rester disponibles pour l’analyse et la livraison.

Avant de supprimer un fichier, le responsable de publication vérifie :

• si la livraison associée est terminée et confirmée ;
• si l’archive possède un emplacement de conservation approuvé ;
• si l’export ou l’envoi est encore en cours ;
• si les symboles sont requis par le suivi des incidents ;
• si le projet peut être réexporté à partir d’un autre artefact valide.

Les certificats, les clés du trousseau et les profils de signature ne doivent pas être traités comme des objets de nettoyage destinés à libérer de l’espace. Leur présence, leurs permissions et leur usage relèvent d’un contrôle d’accès séparé. Une opération de stockage qui détruit un élément de signature peut transformer une panne d’espace en incident de livraison et de sécurité.

La validation finale doit rejouer l’archive, l’export et, lorsque le processus le prévoit, l’étape d’envoi. Une archive réussie sans export vérifié ne suffit pas à déclarer le nœud opérationnel.

Checklist de remise en service

La liste suivante sert de point de passage entre le développeur de permanence, les responsables de construction, de test et de publication. Chaque case doit être cochée avec une preuve attachée au ticket d’incident.

• [ ] Les nouvelles tâches ont été suspendues et aucun processus critique ne continue d’écrire.
• [ ] Le premier message No space left on device, le commit et les paramètres de construction sont conservés.
• [ ] L’espace du volume, les inœuds et les processus actifs ont été relevés.
• [ ] Les dossiers de travail abandonnés ont été distingués du code source et des artefacts de livraison.
• [ ] Le chemin et le propriétaire de DerivedData ont été confirmés pour le compte réellement utilisé.
• [ ] Aucun cache supprimé n’était utilisé par une tâche parallèle.
• [ ] Les runtimes et appareils requis par la matrice d’iOS Simulator sont conservés.
• [ ] Le démarrage du runtime et l’exécution d’un test représentatif ont été vérifiés.
• [ ] Les archives, exports, symboles et éléments de publication ont reçu une décision de conservation.
• [ ] Une construction propre et une construction de réutilisation ont été exécutées.
• [ ] L’archive et l’export ont été validés lorsque la publication faisait partie du périmètre.
• [ ] Le nœud a été remis en service seulement après transmission des preuves et des conditions de retour.

FAQ opérationnelle

Suppression prioritaire

Lorsqu’une construction Xcode échoue pour manque d’espace, la priorité revient aux données produites par une tâche arrêtée et clairement régénérables. Les archives, rapports demandés, fichiers de signature et données d’un test actif restent hors périmètre. La suppression doit être suivie d’une reproduction avec le même commit, sans quoi l’espace libéré ne prouve pas que la cause est traitée.

DerivedData sur un CI distant

DerivedData peut être supprimé dans un CI Mac distant lorsque son chemin est confirmé, que le compte d’exécution est connu et qu’aucune tâche ne l’utilise. La conséquence attendue peut être une recompilation plus longue ou une nouvelle résolution. Le contrôle utile est composé d’une construction propre et d’une construction suivante vérifiant la réutilisation, plutôt qu’un simple retour positif.

Nettoyage d’iOS Simulator

La maintenance d’iOS Simulator doit distinguer le runtime, l’appareil simulé et les données de test. Le runtime requis par la matrice ne doit pas être retiré pour gagner rapidement de l’espace. Les éléments obsolètes sont gérés par les fonctions de Xcode ou les outils documentés, puis validés par un démarrage, une installation, un test et une reprise après interruption.

Runner Mac partagé

Un Runner Mac partagé reste stable lorsque chaque catégorie de données possède un propriétaire, une règle de conservation et un événement de nettoyage observable. La fin d’une tâche ne doit déclencher une suppression qu’après confirmation de l’arrêt des processus et du transfert des artefacts. Une surveillance par répertoire permet ensuite de distinguer la croissance d’un projet de celle d’un cache global.

Nettoyage ou extension

Une extension devient rationnelle lorsque les données nécessaires à la construction, au test et à la publication dépassent régulièrement la capacité disponible malgré une rétention définie. Avant cette décision, éliminez les doublons prouvés, séparez les archives des caches et rejouez le flux complet. Si la saturation revient pendant une charge normale, une nouvelle suppression intégrale ne constitue plus une stratégie de maintenance.

Politique de conservation et décision de capacité

Le responsable de plateforme doit convertir l’incident en règles compréhensibles par les propriétaires de données. L’espace de travail appartient au projet et peut être nettoyé après la fin confirmée de la tâche. Les caches appartiennent à la chaîne de construction et doivent être conservés uniquement lorsqu’ils apportent une réutilisation vérifiable. Les runtimes appartiennent à la matrice de test, tandis que les archives et exports relèvent du cycle de publication.

Une politique exploitable associe chaque catégorie à un déclencheur : fin de tâche, publication confirmée, expiration de conservation ou remise à disposition du nœud. Elle définit également l’exception : enquête d’incident, reprise d’une livraison, analyse de crash ou exigence d’audit. Les suppressions doivent produire un journal indiquant le propriétaire, le chemin, la raison et le résultat de la validation.

Si les tâches de construction, les tests de Simulator et les archives doivent coexister sur le même Mac distant, la plateforme compare trois décisions. La première consiste à raccourcir la conservation des données réellement régénérables. La deuxième consiste à séparer le nœud de construction du nœud de publication afin de protéger les archives. La troisième consiste à choisir une capacité de stockage supérieure après mesure d’une charge réelle.

Pour préparer cette décision, il est préférable de consulter un guide de choix de configuration d’un nœud de construction Mac distant, puis de valider le scénario avec les mêmes projets, paramètres et runtimes que ceux de la chaîne. Une configuration annoncée comme suffisante ne remplace pas un test d’acceptation portant sur le cycle complet.

Quand remplacer le nettoyage par une nouvelle capacité

Le nettoyage répond à une accumulation accidentelle : clone abandonné, archive déjà transférée, appareil simulé inutile ou cache dont la conservation n’a plus de valeur. Il ne répond pas à une charge normale qui produit durablement des artefacts nécessaires. Dans ce cas, effacer le disque à chaque incident augmente le risque de perdre une preuve et reporte la panne à la tâche suivante.

Un nœud destiné à des constructions fréquentes, à des tests iOS Simulator et à des archives simultanées doit être évalué sur la coexistence de ces usages. Les équipes qui ont besoin d’un environnement stable peuvent comparer les options de Mac distant pour les équipes de développement et vérifier le comportement d’un vrai projet avant de modifier leur chaîne.

Le critère d’acceptation n’est pas seulement « la construction passe ». Il inclut la conservation des archives, la disponibilité du runtime requis, la récupération après déconnexion, la réutilisation des caches et la capacité à reprendre une livraison. Une extension ou une séparation devient préférable lorsque ces exigences sont incompatibles avec la capacité actuelle, même après un nettoyage correctement gouverné.

Le modèle de Mac distant évite alors d’immobiliser immédiatement un poste local dédié, mais il ne dispense pas de mesurer les besoins réels. Pour une validation temporaire, un changement de projet ou une période de forte charge, NodeMini permet de tester un environnement Mac distant avec le flux de construction, de test et d’archivage concerné. La décision doit rester fondée sur les preuves recueillies, et non sur une promesse abstraite de capacité.

Dans un environnement actuel où le Runner partagé impose des nettoyages manuels, conserve trop longtemps les caches et mélange les archives avec les tâches de test, la solution locale ou un serveur non adapté présente trois défauts concrets : elle immobilise une machine dédiée, rend la capacité difficile à ajuster et complique la reprise lorsqu’une autre équipe a besoin de macOS. Après le nettoyage sécurisé, louer un Mac auprès de NodeMini peut offrir un terrain de validation plus souple pour les besoins temporaires, les essais de pipeline et les charges créatives audio, vidéo ou design, à condition de vérifier le stockage avec le projet réel.

La bonne action cette semaine est donc de geler les écritures, documenter les catégories d’occupation, appliquer uniquement les suppressions autorisées, puis rejouer la construction, le test et l’archive. Si le volume se remplit encore avec une conservation maîtrisée, choisissez une séparation des rôles, une durée de location adaptée ou une configuration distante plus capacitaire plutôt que de relancer un nettoyage aveugle.