Commencer par le symptôme

Identifiez d’abord le problème, puis passez à l’étape suivante

Saisissez un message d’erreur, un outil ou une méthode de connexion. Cette page ne se limite pas aux explications théoriques : elle détaille dans l’ordre l’état de l’appareil, l’emplacement des journaux, les commandes de vérification et les informations nécessaires pour contacter le support.

Orientation rapide

Choisissez le parcours de vérification correspondant au symptôme

Choisissez d’abord le symptôme le plus proche, puis suivez l’ordre indiqué sur la page. Ne réinstallez pas Xcode, les dépendances ou le Runner avant d’avoir vérifié le réseau et l’état du disque.

Impossible de se connecter à l’appareil Vérifiez l’état, les identifiants, le réseau, le bureau à distance et SSH. Échec de l’archivage ou de la signature Vérifiez la version de Xcode, les certificats, les profils de provisioning et les autorisations du trousseau. La tâche de build ne s’exécute pas Partez de l’état en ligne du Runner et vérifiez la concurrence, le cache, les autorisations et le délai d’expiration. La tâche ralentit soudainement Distinguez la concurrence des ressources, l’augmentation du cache, le manque d’espace disque et les anomalies de la chaîne d’outils.

Première connexion

Cinq points de contrôle pour réduire le périmètre d’un problème de connexion

Les problèmes de connexion se situent généralement au niveau de l’état, des identifiants, du réseau ou de la configuration du client. Respecter l’ordre des vérifications évite de prendre une panne réseau pour une panne de l’appareil.

01

Confirmer l’état de l’appareil

Connectez-vous d’abord à la console pour vérifier que l’instance est disponible, puis contrôlez le nom de l’appareil et le nœud associés à la commande. Si la console indique que l’appareil est disponible mais que les deux méthodes de connexion échouent, vérifiez le réseau. Ne modifiez pas encore la configuration système.

  • Vérifiez le numéro de commande, l’identifiant de l’appareil et le nœud.
  • Vérifiez que vous ne vous connectez pas à une ancienne adresse enregistrée.
  • Notez l’état affiché dans la console et l’heure de la vérification.
02

Vérifier les identifiants d’accès

Distinguez le nom d’utilisateur système, le mot de passe initial et la clé SSH. Lors du copier-coller, vérifiez les espaces en début et en fin. En cas d’échec de l’authentification par clé, confirmez d’abord que la bonne clé privée et le bon nom d’utilisateur sont utilisés ; n’essayez pas plusieurs combinaisons à la suite.

  • Vérifiez la casse du nom d’utilisateur et l’état du mode de saisie.
  • Vérifiez que les permissions du fichier de clé privée ne sont pas trop permissives.
  • En cas de problème d’identifiants, ouvrez un ticket depuis la console.
03

Tester le réseau local

Effectuez un nouveau test depuis un autre réseau fiable et excluez temporairement le proxy d’entreprise, le VPN, le pare-feu sortant et les règles du logiciel de sécurité. Notez l’adresse cible, le port, l’heure et le texte du délai d’expiration.

  • Testez séparément la résolution DNS et le port cible.
  • Comparez les résultats du réseau domestique et du réseau d’entreprise.
  • Ne vous contentez pas d’indiquer « échec de connexion ».
04

Vérifier le bureau à distance

Vérifiez que l’adresse, le nom d’utilisateur et les paramètres d’affichage enregistrés par le client correspondent toujours à l’appareil actuel. Si l’écran s’ouvre mais que les saisies sont retardées, réduisez d’abord la résolution et la qualité des couleurs, puis vérifiez les variations du réseau local.

  • Supprimez l’ancienne connexion dans le client, puis recréez-la.
  • Capturez le texte de l’erreur, sans transmettre d’identifiants sensibles.
  • Vérifiez si SSH peut se connecter indépendamment.
05

Vérifier la configuration SSH

Utilisez la sortie détaillée pour déterminer si l’échec se produit lors de la résolution, de la négociation ou de l’authentification. Si la négociation réussit mais que l’authentification échoue, vérifiez le nom d’utilisateur, la clé privée et le fichier d’autorisation. Si la connexion expire immédiatement, revenez à l’analyse du chemin réseau.

ssh -vvv user@host
chmod 600 ~/.ssh/id_ed25519
ssh-add -l
Limites de sécurité

Ne transmettez pas de mots de passe, clés privées, codes de récupération, informations de paiement complètes ni certificats non désensibilisés dans une demande de support. Pour montrer une configuration, conservez uniquement les champs utiles au diagnostic.

Xcode et signature

Valider séparément la version, la signature et l’archivage

Ne validez pas tous les éléments dans une seule tâche de publication complète. Confirmez d’abord la version de la chaîne d’outils, testez ensuite la signature avec un projet de test, puis consultez les journaux d’archivage du projet réel.

Point de contrôle Résultat de la vérification
XCODE Version et outils en ligne de commande cohérents

Vérifiez que la version sélectionnée dans l’interface, le chemin des outils en ligne de commande et les exigences du projet correspondent. Après un changement de version, rouvrez le terminal et les processus de build.

xcode-select -p
CERT Le certificat est lisible par l’utilisateur actuel

Vérifiez que le certificat requis et sa clé privée sont importés intégralement et accessibles pendant la session de connexion actuelle. La présence du nom du certificat ne suffit pas à confirmer l’importation.

security find-identity -v -p codesigning
PROFILE Le profil correspond à la cible

Vérifiez l’identifiant de l’application, l’équipe, les capacités et la période de validité. Avant de supprimer d’anciens profils, enregistrez leur liste afin de pouvoir revenir en arrière.

~/Library/MobileDevice/Provisioning Profiles
KEYCHAIN Les tâches non interactives disposent des autorisations nécessaires

Si l’archivage fonctionne dans l’interface mais échoue en CI, vérifiez en priorité le Keychain utilisé par la session du Runner, son déverrouillage et ses contrôles d’accès.

security list-keychains
ARCHIVE Conserver la première erreur à l’origine du problème

Dans le journal d’archivage, recherchez le premier échec au lieu de copier uniquement le récapitulatif final. Notez la cible, la configuration, le SDK et la commande exécutée.

xcodebuild -showBuildSettings

Manuel de dépannage CI/CD

Si la tâche ne s’exécute pas, vérifiez d’abord le Runner, puis la tâche

Un incident d’intégration continue doit être décomposé en quatre couches : planification, environnement d’exécution, ressources et scripts. Relancer directement la tâche écrase les journaux de l’incident et ne prouve pas que le problème est résolu.

Symptôme CI/CD, ordre des vérifications et validation du rétablissement
Symptôme Vérification prioritaire Ordre des actions Critère de rétablissement
Runner hors ligne Processus, réseau, informations d’enregistrement, utilisateur d’exécution Vérifiez que l’appareil est accessible, puis consultez les journaux du service ; contrôlez le périmètre d’enregistrement et l’utilisateur de démarrage. Ne réenregistrez pas immédiatement. Le Runner reste en ligne et prend correctement en charge une tâche de test minimale.
Tâche en attente prolongée Étiquettes, limite de concurrence, tâches existantes Vérifiez que les étiquettes de la tâche correspondent au Runner ; recherchez les processus non terminés ou les créneaux d’exécution occupés. La nouvelle tâche est prise dans la file prévue et l’état de l’ancienne tâche est clairement terminé.
Échec de restauration du cache Clé de cache, permissions du répertoire, espace disque disponible Comparez les clés de cache d’une tâche réussie et d’une tâche en échec ; vérifiez le propriétaire du répertoire, puis supprimez le cache reconstructible. Les dépendances sont restaurées et la tâche suivante réutilise la même règle de cache.
Erreur de permissions du script Droit d’exécution, interpréteur, répertoire de travail Vérifiez que le script est bien présent dans le dépôt et conserve son droit d’exécution ; contrôlez l’interpréteur de la première ligne et les chemins relatifs. Le script s’exécute correctement dans une session non interactive de l’utilisateur du Runner.
Délai de build dépassé Dernière étape active, processeur, mémoire, disque Recherchez d’abord le dernier journal valide, puis déterminez s’il s’agit d’un processus bloqué, d’un manque de ressources ou d’une attente liée au réseau. Le même commit s’exécute correctement plusieurs fois, avec une durée proche de la référence et aucun processus résiduel.
RUNNER BASELINE

Conserver une tâche minimale de contrôle de santé

Le contrôle de santé vérifie uniquement le répertoire de travail, le disque, le chemin de la chaîne d’outils et un test court. Il ne doit contenir aucun identifiant de publication ni dépendre d’un cache volumineux.

whoami
pwd
df -h
xcodebuild -version
git --version

Performances et stockage

Déterminer la cause du ralentissement avec trois groupes d’éléments

Un seul ralentissement ne suffit pas à conclure qu’une configuration supérieure est nécessaire. Consultez au minimum le Moniteur d’activité, l’espace disque et les journaux de build, puis comparez-les à la référence habituelle du même projet.

CPU et mémoire

Observez l’ensemble du cycle de la tâche, pas une seule seconde. Un CPU saturé durablement alors que la tâche progresse indique une charge de calcul ; une pression mémoire persistante accompagnée de nombreux échanges indique plutôt que la concurrence ou la taille du projet dépasse peut-être la configuration actuelle.

À relever
Pic, durée, nombre de tâches concurrentes
À exclure
Simulateurs résiduels, processus de compilation non terminés

Disque et cache

Commencez par mesurer l’espace occupé par le projet, les dépendances, les simulateurs, les archives et les caches reconstructibles. Lorsque le disque approche de sa limite, la décompression des dépendances, l’archivage et l’écriture des journaux peuvent devenir instables. Avant tout nettoyage, distinguez les artefacts des données reconstructibles.

À vérifier
DerivedData, archives, simulateurs, caches de paquets
À valider
Relancer le même commit après le nettoyage

Journaux de build et chaîne d’outils

Si les courbes de ressources sont normales mais que la tâche reste bloquée au même script, au téléchargement des dépendances ou à la compilation, vérifiez les changements de version, les dépendances réseau et les conditions d’attente du script. Comparer les journaux d’une exécution réussie permet de trouver plus vite le point de divergence qu’en examinant uniquement la durée totale.

Comparer
Même commit, même chaîne d’outils, même commande
Localiser
Première étape qui s’écarte nettement de la référence
A Ressources saturées en continu

Réduisez la concurrence et refaites un test ; si la durée varie régulièrement avec la concurrence, envisagez une configuration supérieure.

B Disque proche de sa limite

Supprimez les caches reconstructibles, archivez les anciens artefacts et mettez en place un nettoyage après chaque tâche.

C Ressources normales mais étape bloquée

Vérifiez les scripts, les sources de dépendances, la version de la chaîne d’outils et les autorisations des tâches non interactives.

Nœuds et réseau

Quatre nœuds disponibles, un format de rapport réseau unique

NUMACS propose des nœuds à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul) et à Hong Kong. Toutes les combinaisons de répertoires sont disponibles à la commande ; l’état réel est celui renvoyé en temps réel par la console.

SGDisponible

Singapour

Convient aux connexions depuis l’Asie du Sud-Est et les réseaux voisins. Pour le diagnostic, notez l’opérateur local, l’adresse cible, la méthode de connexion et l’heure de l’incident.

Choisir le nœud de Singapour
JPDisponible

Japon (Tokyo)

En cas d’anomalie, testez séparément le bureau à distance et SSH, en précisant si le problème n’apparaît que sur un réseau local particulier.

Choisir le nœud du Japon
KRDisponible

Corée du Sud (Séoul)

Pour signaler un problème réseau, joignez la période du délai ou de la coupure ainsi que le résultat d’un nouveau test du même appareil sur un autre réseau.

Choisir le nœud de Corée du Sud
HKDisponible

Hong Kong

Si la latence interactive change soudainement, notez l’adresse cible, le protocole utilisé, la version du client et la tâche en cours d’exécution.

Choisir le nœud de Hong Kong
Rapport d’incident réseau

Que doit contenir un rapport réseau vérifiable ?

Indiquez l’heure et le fuseau horaire, le nœud, l’adresse cible, le protocole utilisé, le type de réseau local, le texte complet de l’erreur et le résultat d’un nouveau test après changement de réseau. Si vous exécutez des commandes de diagnostic, transmettez le résultat désensibilisé, pas seulement quelques chiffres visibles sur une capture.

  • Heure :À la minute près, avec le fuseau horaire
  • Chemin :Réseau local, adresse cible et port
  • Résultat :Délai dépassé, refus, échec d’authentification ou déconnexion
  • Comparaison :Résultat obtenu sur un autre réseau ou avec une autre méthode de connexion

Facturation et cycles

Vérifiez d’abord le cycle de commande, puis l’historique de paiement

Les appareils peuvent être loués à la journée, à la semaine, au mois ou au trimestre. Les commandes sont réglées en dollars américains (USD) ; le cycle et la configuration applicables sont ceux indiqués dans la commande.

DAY

À la journée

Idéal pour une validation courte, un build ponctuel ou une répétition de migration. Pour toute question de facturation, indiquez l’heure de début de la commande et l’identifiant de l’appareil.

WEEK

À la semaine

Idéal pour un sprint continu ou la validation d’une version. Lors de la vérification, ne confondez pas la semaine civile avec le cycle réel de la commande.

MONTH

Au mois

Idéal pour le développement stable et les workflows d’intégration continue. Avant de changer de configuration, exportez les données nécessaires et confirmez les modalités de migration.

QUARTER

Au trimestre

Idéal pour les projets continus et les Runners dédiés. L’équipe doit anticiper la rotation des identifiants, les sauvegardes et le transfert des tâches.

Vérification avant envoi

Éviter de reprendre le diagnostic depuis le début

Les informations ci-dessous déterminent si le support peut passer directement à la reproduction et à l’identification du problème, au lieu de devoir demander d’abord les éléments de base.

Le bureau à distance et SSH échouent tous les deux : que faut-il transmettre en premier ?

Vérifiez d’abord l’état de l’appareil dans la console, puis transmettez le numéro de commande, le nœud, l’heure et le fuseau horaire, l’adresse cible, le texte complet des erreurs des deux méthodes de connexion et le résultat d’un nouveau test sur un autre réseau local. Ne transmettez ni mot de passe ni clé privée.

Après un échec de build Xcode, faut-il réinstaller immédiatement la chaîne d’outils ?

Ce n’est pas recommandé. Conservez d’abord la première erreur à l’origine du problème, la version de Xcode, le chemin des outils en ligne de commande, la configuration du projet et les dernières modifications. Une réinstallation modifie l’état de l’incident et peut supprimer les différences de versions et les journaux utiles au diagnostic.

Lorsque le Runner est hors ligne, le réenregistrer est-il la solution la plus rapide ?

Vérifiez d’abord la connexion de l’appareil, le processus du Runner, l’utilisateur d’exécution et les journaux du service. Ne réenregistrez le Runner qu’après avoir confirmé que ses informations d’enregistrement sont endommagées ou expirées. Sinon, les anciennes et nouvelles entrées peuvent coexister et compliquer le diagnostic de la planification.

Comment désensibiliser les journaux ?

Conservez l’heure, les commandes, les codes d’erreur, les versions des outils et la structure des chemins utiles au problème ; remplacez les noms d’utilisateur, adresses de dépôt, jetons d’accès, contenus de certificats, clés privées et données métier. Relisez ensuite les journaux désensibilisés pour vérifier que le contexte suffit toujours à reproduire le problème.

Comment accélérer le traitement d’un incident de build urgent ?

Indiquez dans l’objet qu’il s’agit d’un incident de build et fournissez le numéro de commande, le nœud, l’heure, les étapes de reproduction, le résultat attendu, le résultat obtenu et les journaux désensibilisés. Les demandes sont traitées selon leur niveau d’information ; un contexte complet réduit les demandes de précisions.

Escalader vers le support

Transformer l’incident en ticket exploitable

Préparez le numéro de commande, le nœud, l’heure et le fuseau horaire, les étapes de reproduction, le résultat attendu, le résultat obtenu, les actions déjà tentées et les journaux désensibilisés. Les commandes existantes permettent d’ouvrir un ticket depuis la console ; les questions avant-vente, sur les nœuds et sur la facturation peuvent également être envoyées à support@numacs.com.

  • Ne transmettez ni mot de passe, ni clé privée, ni code de récupération, ni informations de paiement complètes.
  • Tout incident de build urgent doit inclure des éléments reproductibles et la première erreur à l’origine du problème.
  • Indiquez la dernière heure de fonctionnement normal et les changements de configuration précédant l’incident.
Ouvrir un ticket dans la console Voir les exigences de contact