Pour un problème de connexion, vérifiez d’abord l’état de la machine et les identifiants. Pour un build, examinez Xcode, les dépendances et la signature. CDNMac fournit une machine physique dédiée, non virtualisée ; le code du projet, les comptes développeur et les éléments de signature restent sous votre responsabilité.
Pour une commande existante, indiquez sa référence, le nœud sélectionné, l’heure du problème et des journaux expurgés. L’état réel de la machine et les actions disponibles sont ceux affichés en temps réel dans la console.
Précisez s’il concerne une seule machine, un dépôt, un build ou tous les modes de connexion.
Testez séparément le réseau, l’accès au système, la chaîne d’outils, les dépendances du projet et la signature. Évitez de modifier plusieurs paramètres à la fois.
Joignez des journaux expurgés, le résultat attendu et les actions déjà tentées. N’envoyez ni clé privée, ni jeton, ni mot de passe de certificat, ni coordonnées de paiement complètes.
Classez le problème d’après son symptôme principal, puis préparez les éléments correspondants. Gardez un seul problème principal par demande ; ajoutez les symptômes associés aux étapes de reproduction.
Indiquez l’état de la machine dans la console, le message d’erreur SSH ou VNC exact, votre réseau local, l’heure de la première occurrence et si un seul mode d’accès est concerné.
Indiquez les versions de Xcode et des Command Line Tools, le fichier de verrouillage utilisé, la commande en échec, le scheme cible, l’espace disque disponible et la première erreur pertinente des journaux.
Joignez le message d’erreur de signature expurgé, le bundle identifier, l’environnement cible et l’état de validité du certificat. N’envoyez ni mot de passe de certificat, ni clé privée, ni jeton utilisable.
Indiquez l’opérateur d’origine, le type de réseau, le nœud cible, la médiane de mesures consécutives et précisez si les téléchargements depuis le dépôt ou des dépendances rencontrent le même problème.
Indiquez la référence de commande, la durée de location, la configuration de base et les options SSD ou Thunderbolt 5 en parallèle concernées. Ne saisissez pas vos coordonnées de paiement complètes dans le ticket.
Indiquez le nœud actuel, la direction de connexion souhaitée, les répertoires de travail et les artefacts à conserver, ainsi que votre accord éventuel pour redéployer l’environnement. Les options disponibles sont celles affichées en temps réel dans la console.
Terminez chaque étape et notez le résultat avant de passer à la suivante. Évitez de changer simultanément les clés, le pare-feu et le réseau local : il serait difficile d’identifier la cause réelle.
Vérifiez la commande et l’état de la machine dans la console, puis contrôlez le nœud actuel et l’identifiant de la machine. Si l’état évolue, attendez un résultat stable avant de tester la connexion.
Assurez-vous d’utiliser le nom d’utilisateur système, l’adresse de l’hôte et les identifiants les plus récents correspondant à cette machine. N’utilisez pas les informations de connexion d’une autre commande.
Depuis un réseau de confiance, vérifiez que l’hôte et le port sont accessibles, puis contrôlez les permissions du fichier de clé et les erreurs d’authentification. Conservez le message d’erreur horodaté, sans envoyer le contenu de la clé privée.
Si SSH fonctionne mais que la session graphique pose problème, notez séparément le client VNC, l’étape de connexion et l’état de l’écran. Ne classez pas un problème de session graphique comme une panne réseau générale.
Vérifiez si le réseau de l’entreprise, le VPN, les règles de sortie ou le pare-feu de votre machine bloquent le port cible. Refaites le test depuis un autre réseau de confiance pour déterminer si le problème vient de votre liaison locale.
Un seul ping indique uniquement le temps aller-retour à cet instant. Il ne permet pas d’évaluer la fluidité de VNC, la vitesse de téléchargement des dépendances ni la durée totale d’un build. Effectuez des mesures répétées et testez vos tâches réelles.
Les journaux de build contiennent souvent des erreurs en cascade. Repérez d’abord la première erreur qui interrompt réellement le processus, puis vérifiez l’outil, les dépendances, la signature ou l’espace disque concernés.
Indiquez la version complète de Xcode, la plateforme cible, le scheme, la configuration et le chemin de l’outil réellement utilisé. Les versions utilisées dans l’interface graphique et en ligne de commande doivent être identiques.
Vérifiez que le répertoire développeur sélectionné et la version attendue correspondent. Après une mise à niveau de Xcode, contrôlez à nouveau le chemin des outils en ligne de commande pour éviter que les scripts n’utilisent un ancien chemin.
Conservez le fichier de verrouillage utilisé par le projet et notez la commande de restauration des dépendances et la stratégie de cache. Recommencez dans un répertoire de travail propre avant de conclure à un cache corrompu.
Vérifiez que l’état de validité, le bundle identifier, l’environnement cible et la configuration de signature concordent. Ne transmettez que des erreurs expurgées, jamais de clé privée ni de mot de passe de certificat.
Vérifiez l’espace occupé par le code source, le cache des dépendances, DerivedData, les archives et les fichiers exportés. Si l’espace manque, commencez par supprimer les caches pouvant être recréés.
Conservez les heures de début de la tâche, de la première erreur et de fin. Précisez si l’échec survient pendant la restauration des dépendances, la compilation, l’archivage, la signature ou l’export.
Les CDNMac M4 peuvent exécuter des builds iOS déclenchés par un dépôt. Pour les intégrer à GitHub Actions, GitLab CI, Jenkins ou à un autre système d’orchestration, considérez le nœud comme une machine de build persistante, et non comme un conteneur éphémère.
Acceptez les tâches selon le dépôt, la branche et les labels du runner.
Utilisez le fichier de verrouillage et un cache propre au dépôt, puis notez les résultats du cache.
Fixez le chemin Xcode, le scheme, la configuration et les paramètres d’export.
Copiez les artefacts nécessaires, nettoyez le répertoire temporaire et conservez des journaux de diagnostic expurgés.
L’emploi d’une terminologie cohérente dans le ticket permet de distinguer plus vite la machine physique, le protocole d’accès, l’exécuteur automatisé et les fichiers livrés.
Un contexte complet facilite la reproduction bien mieux que des messages courts envoyés à répétition. Pour les informations sensibles, indiquez le type et l’état, sans transmettre de données en clair utilisables.
Indiquez la référence de commande ou de machine visible dans la console afin d’identifier le modèle, la durée de location et l’historique de la machine.
Précisez le nœud actuel de la machine au lieu d’indiquer simplement « Asie » ou « États-Unis ». En cas de migration, indiquez également la destination souhaitée.
Notez la première occurrence, la dernière reproduction et l’heure de fin de la tâche, en précisant le fuseau horaire pour faciliter la vérification des données de la machine et du réseau.
Décrivez dans l’ordre les entrées, commandes, cibles et résultats. Si le problème est intermittent, précisez sa fréquence et les conditions qui le déclenchent.
Conservez le contexte de l’erreur et les horodatages, mais retirez les clés privées, jetons, mots de passe de certificat, données personnelles et coordonnées de paiement complètes.
Indiquez l’état, le fichier ou la valeur de retour normalement attendus, ainsi que les actions déjà tentées sans succès.
Distinguer les problèmes liés à la machine et au réseau, à l’accès au système, aux outils et au projet lui-même évite de modifier inutilement des paramètres au mauvais niveau.
Nous vous aidons à vérifier l’état de la machine, le réseau côté nœud, le lien avec la commande et les informations de gestion visibles dans la console, puis à poursuivre l’analyse à partir d’éléments reproductibles.
Pris en charge par CDNMacNous vous aidons à déterminer si la machine est joignable, si les identifiants correspondent à la machine et si un problème SSH ou VNC relève du réseau, de l’authentification ou de la session.
Pris en charge par CDNMacÀ partir des journaux, nous pouvons vous aider à examiner Xcode, les Command Line Tools, l’espace disque et les étapes du build. Votre équipe reste responsable de vérifier les dépendances et les scripts du projet.
Diagnostic partagéVotre équipe gère le code du projet, les comptes développeur, les certificats, les profils de provisionnement, les clés d’accès, les licences logicielles, les versions des dépendances et la conformité des charges de travail.
À la charge de l’utilisateurUne machine dédiée limite le partage des ressources, mais ne remplace pas la gestion des accès de votre équipe. Prévoyez des procédures claires pour la première connexion, l’utilisation courante et la fin de la location.
N’accordez aux jetons CI, aux clés de dépôt et aux comptes automatisés que les droits requis par la tâche. Évitez que plusieurs projets partagent durablement les mêmes identifiants privilégiés.
Tenez un registre du renouvellement des clés et des jetons. Révoquez rapidement les accès devenus inutiles lorsqu’un membre, un dépôt ou une tâche change.
Vérifiez régulièrement la validité des certificats et des profils de provisionnement. Supprimez les copies inutilisées afin que le pipeline ne sélectionne pas une ancienne configuration par erreur.
Avant la fin de la location, copiez les modifications du code source, les journaux de build, les archives et les artefacts nécessaires vers un stockage contrôlé par l’équipe, puis vérifiez que les fichiers sont lisibles.
Indiquez la référence de commande, le nœud, l’heure, les étapes de reproduction, des journaux expurgés et le résultat attendu. N’envoyez ni clé, ni jeton, ni mot de passe de certificat en clair.