Guide de dépannage pour les charges iOS, macOS, CI/CD et Apple Silicon. Vérifiez d’abord le nœud et le réseau, puis la chaîne d’outils et les logs afin de ne pas modifier plusieurs variables à la fois.
La console affiche les informations du nœud associé à la commande en cours. Lorsque vous copiez les champs, conservez leur format d’origine et ne devinez ni l’adresse, ni le nom d’utilisateur, ni le port.
Connectez-vous à la console et vérifiez la commande, la région, l’adresse de l’hôte, le nom d’utilisateur et les modes de connexion autorisés. Le nœud se trouve à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul), à Hong Kong, dans l’est des États-Unis ou dans l’ouest des États-Unis.
Vérifiez que le réseau professionnel ne bloque pas le port cible, désactivez les proxys temporaires qui modifient le routage et notez séparément les résultats obtenus sur les réseaux filaire, Wi-Fi ou autres.
Privilégiez SSH pour la ligne de commande, la synchronisation de fichiers et les tâches automatisées ; utilisez VNC pour accéder à l’interface graphique de macOS. Lors du premier test, n’établissez qu’un seul type de connexion afin d’éviter les interférences.
Après la connexion, notez la version du système, l’espace disque disponible, le chemin Xcode et l’heure réseau actuelle. Exécutez d’abord un projet minimal, puis migrez le projet complet et le cache de build.
Ne téléversez pas un projet complet, ne modifiez pas les réglages système et n’enregistrez pas encore le runner CI tant que la connexion n’est pas stable. Conservez d’abord un résultat de référence reproductible.
En cas d’échec de connexion, partez des informations d’identité et progressez vers les couches réseau. Ne modifiez qu’une condition à la fois et conservez la sortie des commandes ou les messages d’erreur.
Vérifiez que le nom d’utilisateur, la clé ou le mot de passe de connexion provient de la commande actuelle ; ne réutilisez pas les informations d’une commande terminée. Contrôlez les permissions du fichier de clé et l’absence d’espaces ou de retours à la ligne ajoutés lors de la copie.
Effectuez un test de connectivité avec le port affiché dans la console. Un délai d’attente indique généralement un problème de chemin réseau ; un refus immédiat signifie souvent que la cible est joignable mais que le service ou le port ne correspond pas.
Vérifiez les logiciels de sécurité du terminal, les règles de sortie de l’entreprise et celles du routeur. Refaites le test depuis un autre réseau connu pour distinguer rapidement une restriction locale d’un problème côté nœud.
Notez la latence, la gigue et les pertes de paquets, plutôt que de vous limiter à un seul ping. VNC est plus sensible à la gigue continue, et un build SSH peut aussi s’interrompre si une connexion de téléchargement est réinitialisée.
Retournez dans la console pour vérifier l’état de l’instance et de la commande. Si la connexion échoue depuis plusieurs réseaux malgré des identifiants corrects, notez l’heure et le message d’erreur exacts, puis ouvrez un ticket pour anomalie du nœud.
Un même commit peut produire des résultats différents selon la chaîne d’outils. Validez séparément l’environnement système et les dépendances du projet afin de déterminer si le problème vient du nœud, de la chaîne d’outils ou de la configuration du dépôt.
xcodebuild -version et notez les versions de Xcode et du build.xcode-select -p et vérifiez que Command Line Tools pointe vers le répertoire attendu.sw_vers
xcodebuild -version
xcode-select -p
df -h
La réussite de l’enregistrement du runner ne garantit pas un workflow sûr et reproductible. Le périmètre d’exécution, le répertoire de travail, les identifiants et la stratégie de concurrence doivent être définis ensemble.
Utilisez les informations d’enregistrement temporaires fournies par le projet ou l’organisation et définissez des labels indiquant la puce, la région et l’usage. Une fois l’enregistrement terminé, supprimez l’historique local des commandes temporaires.
Livrable : nom du runner et liste des labelsAutorisez uniquement les dépôts de confiance, les branches protégées et les workflows explicitement habilités à appeler le nœud. Les tâches déclenchées par des contributions externes doivent être examinées ; aucun script inconnu ne doit obtenir directement l’accès au nœud.
Livrable : règles d’autorisation des dépôts et branchesTraitez les fichiers temporaires, données dérivées et caches inutiles avant et après chaque tâche. Si vous conservez un cache, notez sa clé, sa source et ses conditions d’expiration afin d’éviter qu’un ancien artefact ne contamine un nouveau build.
Livrable : script de nettoyage et stratégie de cacheGérez les jetons, clés SSH et éléments de signature dans un processus contrôlé de gestion des secrets. Révoquez-les et réémettez-les immédiatement lorsqu’un membre quitte l’équipe, que les droits du dépôt changent ou qu’un log anormal apparaît.
Livrable : responsable des identifiants et historique de rotationNe vous contentez pas du code de sortie générique à la fin du log. Conservez le log complet et, à la première erreur, remontez pour lire la cible, la commande et le contexte des dépendances.
| Catégorie de panne | Signaux fréquents dans les logs | Vérifier en premier | Éléments à joindre au ticket |
|---|---|---|---|
| Résolution des dépendances | Conflit de versions de packages, échec de récupération du dépôt, fichier de verrouillage incohérent | Fichier de verrouillage, source des dépendances, clé de cache et résultat du téléchargement réseau | Mode de gestion des dépendances, nom du package en échec, premier bloc d’erreur |
| Configuration de signature | Échec de correspondance du certificat, autorisation indisponible, variable de configuration manquante | Scheme, configuration de build et processus d’injection des secrets | Message d’erreur désensibilisé et cible de build |
| Échec des tests | Échec d’assertion, différence d’environnement simulé, délai d’attente du test | Cas en échec, destination, paramètres de parallélisme et résultat des nouvelles tentatives | Nom du cas, code de sortie, commande reproductible |
| Téléchargement réseau | Connexion réinitialisée, échec de résolution, délai d’attente du téléchargement | Nouvelles requêtes vers la même adresse, DNS, proxy et chemin de sortie | Heure de l’incident, type de cible et résultats des tests réseau |
Conserver le log brut complet
Identifier la première erreur utile
Reproduire séparément avec la commande minimale
Supprimer les identifiants avant d’envoyer un extrait
Augmenter la capacité ne remplace ni la classification des données ni les sauvegardes. Définissez d’abord ce qui doit être conservé, puis choisissez le mode de synchronisation, de mise en cache et de migration.
Synchronisez en priorité le code source via le dépôt de versions, et placez les gros binaires et dépendances privées dans un stockage contrôlé. Après la première migration, comparez le hash du commit, les sous-modules et les fichiers de verrouillage.
DerivedData, le cache des packages et le répertoire de travail du runner peuvent tous affecter la reproductibilité. Avant de supprimer quoi que ce soit, notez la taille des répertoires et les clés de cache, puis comparez la durée du build et l’évolution des erreurs.
Le SSD supplémentaire sert aux projets, caches ou jeux de données nécessitant davantage d’espace de travail. Vérifiez le point de montage, les chemins de lecture/écriture et les droits des tâches avant de commencer le travail en production.
Sauvegardez les données du projet, éléments de signature, identifiants et artefacts de build selon la stratégie de l’équipe. Terminez la migration avant la fin de la période de location et vérifiez que les copies sont lisibles ; ne considérez pas l’unique copie présente sur le nœud comme une archive durable.
Plus votre demande est précise, plus elle peut passer directement à la reproduction et à l’analyse. Commencez par l’impact, puis fournissez la chronologie et les logs minimaux, sans envoyer de secret.
Mots de passe, clés privées, codes de récupération, jetons complets, éléments de signature et justificatifs de paiement complets. Si un log contient un secret, supprimez-le ou remplacez-le d’abord par un marqueur de désensibilisation explicite.
Connectez-vous à la console, créez un ticket et sélectionnez la commande correspondante afin d’aider le support à vérifier le bon nœud et l’historique du service.
Créer un ticket depuis la consoleUne interruption de connexion, une anomalie du nœud et une question de facturation nécessitent des éléments différents. Choisissez la bonne catégorie et ajoutez les informations dans la même conversation afin de conserver le contexte.
Joignez le type de réseau local, le test du port cible, le message d’erreur exact et l’heure de l’incident. Si une autre connexion réseau rétablit le service, indiquez également la différence entre les deux tests.
Catégorie : Connexion et accèsIndiquez le périmètre de l’impact, la dernière heure de fonctionnement normal, l’état de l’instance et la commande minimale de reproduction. N’écrasez pas l’état initial par des redémarrages répétés ou des modifications massives de configuration.
Catégorie : Fonctionnement du nœudIndiquez l’identifiant de la commande, la période de facturation, les options concernées et la description du problème. Toutes les commandes sont réglées en dollars américains (USD) ; n’envoyez pas de justificatif de paiement complet dans le ticket.
Catégorie : Commandes et facturationMettez à jour l’avancement, les questions complémentaires et la conclusion finale dans le ticket correspondant de la console. Lorsque vous ajoutez de nouveaux logs, indiquez l’heure de collecte et les modifications effectuées pour faciliter la comparaison.
Les nouvelles commandes permettent de choisir deux configurations et six nœuds ; pour un problème concernant une commande existante, connectez-vous à la console et ouvrez un ticket associé.