Cette page couvre les connexions, les builds Xcode, les runners CI/CD, le stockage, le réseau des nœuds et la facturation des nœuds Mac physiques dédiés. Effectuez d’abord les vérifications de base dans l’ordre indiqué. Si le problème persiste, envoyez la commande, l’environnement et les logs expurgés afin de limiter les échanges.
Ne modifiez pas simultanément le réseau, la version du système et la configuration du build. Ne changez qu’une variable à la fois et conservez le message d’erreur d’origine ainsi que l’heure afin de déterminer si le problème relève de la connexion, de l’environnement ou du projet.
Vérifiez d’abord l’adresse du nœud, le port, le nom d’utilisateur et les identifiants, puis examinez les restrictions réseau locales, les options de chiffrement du client et l’état de la session. Ne réessayez pas constamment avec d’anciens identifiants.
Ouvrir les étapes de vérification de la connexionNotez l’étape de l’échec, puis vérifiez l’espace disque, les versions de Xcode et du SDK, le fichier de verrouillage des dépendances, les éléments de signature et les logs complets du build. Conservez en priorité la première erreur réelle.
Voir l’ordre du diagnostic des buildsVérifiez le processus du service runner, son état d’enregistrement, la correspondance des labels, les droits du répertoire de travail et la limite de concurrence. Un statut en ligne sur la plateforme ne garantit pas que les labels de la tâche actuelle correspondent.
Vérifier la configuration du runnerDistinguez l’espace occupé par le code source, le cache des dépendances, DerivedData, les archives et les artefacts livrés. Exportez d’abord les fichiers nécessaires, puis nettoyez répertoire par répertoire ; ne supprimez pas directement des données dont l’usage est incertain.
Lire la FAQ sur le stockageNotez le nœud actuel, la région d’hébergement du dépôt, l’emplacement des principaux opérateurs et le sens des transferts de gros fichiers avant d’évaluer une migration. Préparez impérativement une copie indépendante du code et des artefacts de build.
Comparer les nœuds et le réseauPréparez le numéro de commande, la configuration choisie, la période de facturation, le mode de paiement et l’état affiché dans la console. Envoyez uniquement l’identifiant de transaction, jamais les informations complètes de carte ni une clé privée.
Soumettre un ticket de facturation depuis la consoleLors de votre première connexion au nœud, effectuez d’abord les vérifications de connexion et de sécurité, puis configurez l’environnement de développement. Vous séparerez ainsi les problèmes système des problèmes de dépendances du projet et faciliterez leur reproduction.
Vérifiez le nœud associé à la commande, l’adresse du serveur, le port, le nom d’utilisateur et les identifiants temporaires. Les informations de connexion sont réservées aux membres actuellement autorisés et ne doivent pas être transmises dans des historiques de chat ou des documents publics.
Critère de réussite : une session stable est établie et vous avez confirmé l’accès au nœud associé à la commande.Après la première connexion, remplacez les identifiants temporaires et créez des comptes système conformes à la stratégie d’accès de l’équipe. Réservez les opérations d’administration aux membres qui doivent installer des outils ou modifier des services.
Critère de réussite : les identifiants temporaires ne sont plus utilisés et les rôles des comptes courants et administrateurs sont distincts.Consignez la version de macOS, la puce, l’espace disque disponible, la version de Xcode, le chemin des outils en ligne de commande et le SDK cible. L’équipe doit inscrire ces informations dans son propre guide d’exploitation des builds.
Critère de réussite : un même ensemble de versions permet d’expliquer les écarts entre les builds locaux et ceux dans le cloud.Installez les dépendances à partir du fichier de verrouillage du projet, définissez un répertoire de cache séparé, puis enregistrez le self-hosted runner. Pour la première tâche, utilisez une faible concurrence afin de valider la signature, l’archivage et le parcours d’upload.
Critère de réussite : une tâche de build minimale peut être exécutée de façon répétée et laisse des logs complets.Récupérez d’abord un commit dont le build est connu comme fonctionnel, puis exécutez uniquement l’installation des dépendances, la compilation et l’archivage. Après validation, ajoutez les tâches parallèles, la restauration du cache et les étapes de livraison.
Préparer la vérification de la connexionLes problèmes de build se répartissent généralement en six couches : espace, signature, versions, dépendances, logs et concurrence. Après chaque couche, relancez le même commit et notez l’évolution du résultat.
Vérifiez séparément l’espace disponible sur le volume système, DerivedData, le cache des dépendances, le répertoire d’archives et les artefacts exportés. En cas de manque d’espace, sauvegardez d’abord les artefacts nécessaires, puis nettoyez répertoire par répertoire.
Vérifiez que l’équipe sélectionnée par le projet, l’état du certificat, la cible du profil de provisioning et le Bundle Identifier correspondent. N’ajoutez jamais de clé privée de signature aux logs ou aux tickets.
Consignez le chemin de Xcode réellement utilisé pour le build, vérifiez que les outils en ligne de commande ne pointent pas vers une autre version et assurez-vous que le SDK cible requis par le projet est disponible.
Comparez le cache au fichier de verrouillage pour déterminer s’il est obsolète. Essayez d’abord un build propre sans restaurer le cache ; s’il réussit, restaurez ensuite les caches de dépendances un par un afin d’identifier la source de l’incohérence.
Conservez la commande exécutée, le code de sortie et la première erreur réelle. Une simple capture du dernier écran omet souvent l’échec initial ; joignez des logs expurgés couvrant toute la tâche, du démarrage à la fin.
Ramenez la concurrence à une seule tâche reproductible et observez l’utilisation de la mémoire, du disque et du réseau. Si une tâche réussit mais que l’exécution parallèle échoue, augmentez progressivement la concurrence pour trouver une limite stable.
Si les six niveaux de vérification ne permettent toujours pas d’identifier la cause, envoyez l’identifiant du commit en échec, la commande exécutée, les versions de l’environnement, le code de sortie et les logs expurgés.
Soumettre un ticket concernant le buildUn nœud physique dédié convient comme self-hosted runner, mais sa stabilité dépend d’une stratégie d’enregistrement claire, des labels, de la gestion du service, des limites de cache et du contrôle des droits.
Utilisez un nom de runner unique pour chaque nœud et consignez le dépôt ou l’organisation, la portée de l’enregistrement, le répertoire de travail et le compte de service. Lors d’une migration, révoquez d’abord l’ancien enregistrement.
Les labels doivent décrire des caractéristiques stables, comme l’architecture de la puce, la version majeure de Xcode, la région du nœud et son usage. N’empilez pas des noms de projets temporaires dans une combinaison difficile à maintenir.
Exécutez le runner comme un service géré et consignez son mode de démarrage ainsi que l’emplacement des logs. Après un redémarrage du système, vérifiez la reprise automatique du service et testez une tâche minimale.
Gérez les dépendances, DerivedData et les archives dans des répertoires distincts et définissez des seuils de nettoyage. Le cache accélère les builds ; il ne doit pas constituer l’unique copie du projet ni un dépôt de livraison permanent.
Le compte de build quotidien ne doit disposer que des droits sur les répertoires et commandes nécessaires à la tâche. Utilisez les droits administrateur uniquement pour installer des outils, modifier la configuration système ou gérer des services.
Processus du service → Validité de l’enregistrement → Correspondance des labels → Droits du répertoire de travail → Connexion externe → File des tâches de la plateforme.
Employer une terminologie cohérente dans les tickets évite de confondre nœud physique, session distante, runner et cache de build comme s’il s’agissait d’un seul et même objet défaillant.
VMArm propose 5 régions de nœuds : Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et l’ouest des États-Unis. Comparez aussi l’utilisation à distance, les clones du dépôt, le téléchargement des dépendances et l’upload des artefacts.
Convient aux équipes d’Asie du Sud-Est ainsi qu’aux dépôts et chaînes de livraison principalement situés dans cette région.
Convient aux équipes du Japon et d’Asie de l’Est, en conciliant l’utilisation du bureau à distance et l’accès aux ressources de build régionales.
Convient aux développeurs, miroirs de dépendances et processus de livraison en Corée et en Asie du Nord-Est.
Convient aux équipes collaborant depuis la Chine méridionale et l’Asie du Sud-Est. Testez à la fois le dépôt et la session distante avant de choisir.
Convient aux équipes de la côte ouest de l’Amérique du Nord et aux projets dont le dépôt, les sources de dépendances ou le système de livraison se trouvent principalement en Amérique du Nord.
| Objet vérifié | Méthode de mesure | Informations à consigner | Point à déterminer |
|---|---|---|---|
| Session distante | Testez séparément la connexion et l’interaction pendant les heures de travail et en dehors des pics | Réseau local, nœud, version du client, heure de l’incident | Anomalie continue ou fluctuation à certaines heures |
| Dépôt de code | Avec le même dépôt et le même commit, testez le clonage, la récupération et les sous-modules | Région du dépôt, durée, commande en échec, code de sortie | Établissement de la connexion lent ou transfert de gros fichiers lent |
| Téléchargement des dépendances | Effectuez une résolution complète des dépendances après avoir désactivé le cache | Source des dépendances, version du gestionnaire de paquets, paquet en échec et nombre de tentatives | Anomalie d’une seule source ou anomalie générale de la bande passante |
| Upload des artefacts | Comparez le transfert avec un fichier de test expurgé de même taille | Taille du fichier, région cible, heures de début et de fin | Influence de la liaison montante, du service cible ou de la taille du fichier |
L’objectif d’un ticket n’est pas de prouver l’existence du problème, mais de permettre au support d’identifier la même commande, le même nœud, le même moment et la même étape en échec.
Permet de confirmer la configuration associée, la période de facturation et l’historique de livraison.
Indiquez Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong ou l’ouest des États-Unis.
Fournissez l’heure avec son fuseau et précisez si le problème est reproductible.
Indiquez la version complète de macOS, et pas uniquement son nom de version majeure.
Indiquez également la version et le chemin vers lesquels pointent réellement les outils en ligne de commande.
Partez d’un état normal et décrivez chaque étape selon l’ordre réel des clics ou des commandes.
Conservez le contexte de l’erreur et le code de sortie, en supprimant les jetons, clés privées et autres informations sensibles.
Connectez-vous, sélectionnez la commande concernée et envoyez votre problème. Le contexte de la commande et du nœud est alors plus complet, ce qui convient aux problèmes de connexion, de build, de migration et de facturation.
Accéder à la consoleAvant de passer commande, indiquez l’usage, la configuration cible, le nombre de builds simultanés, la région souhaitée et la date prévue de mise en service.
Voir les moyens de contactAvant l’envoi, supprimez les jetons d’accès, les clés privées de signature, les informations complètes de paiement et tout autre contenu sensible. Pour connaître les modalités de traitement des données, consultez lapolitique de confidentialité.
L’ordre de réponse dépend de l’impact et de la reproductibilité. Le support prend en charge la livraison des nœuds, les connexions, l’environnement et les commandes ; la logique métier du projet doit être vérifiée par ses responsables.
Évaluez l’impact selon que la connexion est impossible, que le build est totalement bloqué, que certaines tâches seulement échouent ou qu’il s’agit d’une simple demande, puis vérifiez l’existence d’une solution de remplacement viable.
Nous confirmons la réception du numéro de commande, du nœud, de l’heure, de l’environnement et des logs. Si une information nécessaire manque, les champs à compléter sont clairement indiqués.
Indiquez la couche en cours d’examen, les éléments écartés, la prochaine vérification et les tests à effectuer, afin d’éviter de répéter des étapes sans nouvelle information.
Le ticket entre dans le processus de clôture lorsque le problème est résolu, que sa cause et les moyens de l’éviter sont expliqués, ou qu’il relève de la configuration du projet et qu’une piste de vérification exploitable a été fournie.
Choisissez VMArm M4 Core ou VMArm M4 Plus, puis sélectionnez une région parmi Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et l’ouest des États-Unis. La disponibilité réelle est celle renvoyée en temps réel par la console.