De la connexion aux outils de développement et au renouvellement, commencez par identifier l’origine du problème.
Les clients disposant d’une location peuvent ouvrir un ticket depuis la console ; les nœuds inaccessibles sont traités en priorité comme des incidents urgents.
Les tickets sont réservés au dépannage des nœuds loués. Pour les demandes avant-vente, les locations en volume et les signalements de sécurité, utilisez l’adresse e-mail indiquée sur la page de contact.
Ces quatre catégories nécessitent des démarches différentes. Un paiement non confirmé ne signifie pas que le nœud est en panne, et un échec de build ne nécessite pas forcément de redémarrer la machine.
Délai d’attente SSH, écran noir sur le bureau distant ou problème d’affichage du partage d’écran. Vérifiez d’abord les informations de commande et le réseau, puis déterminez si le problème vient de la connexion ou de la session graphique.
La ligne de commande utilise la mauvaise version de Xcode, le cache occupe trop d’espace disque ou l’identité de signature est introuvable. Comparez les versions et vérifiez le trousseau pour repérer les différences d’environnement.
Le build fonctionne dans le terminal interactif, mais échoue dans le pipeline. Vérifiez d’abord l’utilisateur d’exécution, le PATH, le trousseau et l’état des simulateurs, plutôt que d’augmenter le nombre de tâches parallèles.
Virement crypto en attente de vérification, paiement par carte refusé ou date d’expiration incertaine. Fiez-vous au statut de la commande et au résultat de paiement affichés en temps réel dans la console.
L’adresse de l’hôte, le port de connexion, le nom d’utilisateur et les exigences liées à la clé figurent dans les détails de la commande, accessibles depuis la console. Renseignez d’abord les variables des commandes ci-dessous en fonction de votre commande ; l’alias donné en exemple n’est pas l’adresse réelle du nœud.
Commencez par distinguer un délai d’attente d’un échec d’authentification. Un délai d’attente survient généralement avant l’établissement de la connexion TCP : vérifiez l’adresse, le port, la sortie réseau locale et l’état du nœud. Si le message Permission denied s’affiche, l’authentification a commencé : vérifiez le nom d’utilisateur et la clé au lieu de changer de port à répétition.
nc -vz "$NODE_HOST" "$SSH_PORT"Exécutez cette commande dans un terminal local. Une connexion réussie confirme uniquement que le port est accessible, pas que l’authentification a abouti. En cas d’échec, refaites le test depuis un autre réseau disponible et consignez les deux résultats. Si le port est accessible mais que la connexion échoue, utilisez ssh -vv pour recueillir les journaux de la phase d’authentification. Avant de les transmettre, supprimez les informations sensibles, comme le nom d’utilisateur, l’adresse et les chemins locaux.
Si le client est connecté mais que l’écran reste noir, le problème diffère d’un port totalement inaccessible. Déconnectez les connexions graphiques en double, puis vérifiez la qualité d’image du client et la session de bureau. Si SSH fonctionne toujours, vous pouvez vérifier l’utilisateur de la console pour déterminer si une session graphique est déjà ouverte.
stat -f '%Su' /dev/consoleExécutez cette commande dans une session SSH sur le nœud. Le résultat n’est qu’un indice et ne suffit pas à confirmer le bon fonctionnement du service de bureau. Ne terminez pas un processus inconnu et ne redémarrez pas un nœud en cours de build. Indiquez dans le ticket l’heure d’apparition de l’écran noir, le nom du client, la disponibilité de SSH et le résultat de la vérification de session ; l’assistance poursuivra le diagnostic.
Déterminez d’abord si la résolution distante a changé ou si le texte est flou à cause de la mise à l’échelle du client local. Vérifiez les options de mise à l’échelle et de qualité adaptative du partage d’écran, puis consultez les informations d’affichage à distance. Modifier la taille de la fenêtre du client ne change pas le mode d’affichage distant.
system_profiler SPDisplaysDataTypeExécutez cette commande sur le nœud et consultez les informations d’affichage. Si le mode attendu n’apparaît pas, notez la résolution actuelle, la taille de la fenêtre du client et les modes d’affichage disponibles. Sur les captures d’écran, ne conservez que la zone des réglages d’affichage, sans contenu de projet, identifiants ni données métier. N’installez pas de pilote d’affichage provenant d’une source inconnue comme première mesure.
Si SSH et la connexion graphique sont tous deux inaccessibles et que le problème persiste après un changement de réseau, ouvrez directement un ticket pour nœud inaccessible. Réinstaller le client à répétition ne remplace pas le signalement de l’incident.
Conservez d’abord les journaux d’erreur, puis modifiez l’environnement. Les opérations ci-dessous concernent votre nœud physique dédié. Avant d’exécuter une commande nécessitant des privilèges, vérifiez qu’aucune autre tâche d’équipe n’utilise cet environnement.
Exécutez d’abord xcode-select -p et xcodebuild -versionpour noter le répertoire développeur et la version actuels. Vérifiez que la version de Xcode voulue est installée, puis définissez son répertoire développeur sur Contents/Developer. Le chemin ci-dessous correspond à une installation nommée Xcode.app. Si l’application installée sur le nœud porte un nom incluant un numéro de version, adaptez le chemin en conséquence.
xcode-select -p
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcodebuild -versionUn processus CI peut remplacer le choix du système via DEVELOPER_DIR . Si les versions utilisées dans le terminal et le pipeline diffèrent, vérifiez les variables d’environnement du job et l’utilisateur du service runner, pas seulement les réglages système. Si une tâche doit utiliser une autre version, définissez explicitement le répertoire développeur dans cette tâche afin de ne pas affecter les autres builds du nœud.
Vérifiez d’abord l’espace occupé, puis décidez si un nettoyage s’impose. Vous pouvez intervenir sur DerivedData après un changement de chaîne d’outils, en cas d’erreur liée au cache, d’indexation anormale ou de manque d’espace disque. Une erreur de compilation ordinaire ne vient pas nécessairement du cache. Après avoir arrêté les tâches de build concernées, renommez le dossier de cache pour pouvoir revenir en arrière : c’est plus facile à vérifier qu’une suppression récursive.
du -sh "$HOME/Library/Developer/Xcode/DerivedData"
mv "$HOME/Library/Developer/Xcode/DerivedData" "$HOME/Library/Developer/Xcode/DerivedData.backup.$(date +%s)"Renommez le dossier uniquement s’il existe. Xcode recréera le cache au prochain build. Le renommage ne libère pas d’espace disque : attendez que le nouveau build fonctionne, puis supprimez l’ancien cache à partir du chemin de sauvegarde réel. Conservez les archives nécessaires ; ne supprimez pas en même temps Archives, le dossier du projet ni les éléments de signature. Si CI utilise un chemin personnalisé via -derivedDataPath, vérifiez ce chemin plutôt que le dossier par défaut de l’utilisateur actuel.
Pour signer, il faut un certificat valide et la clé privée qui lui est associée. Le fichier de certificat seul ne suffit généralement pas. Importez les éléments de signature que vous êtes autorisé à utiliser avec Trousseaux d’accès, puis vérifiez les identités disponibles sous l’utilisateur qui exécute réellement le build. Ne joignez ni certificat ni mot de passe d’importation au ticket.
security find-identity -v -p codesigning
security list-keychains -d userLe fait qu’une identité soit visible pour l’utilisateur interactif ne garantit pas qu’elle le soit pour l’utilisateur du service runner. Vérifiez aussi le compte d’exécution du service, la liste de recherche des trousseaux, leur état de déverrouillage et les autorisations d’accès. Si vous devez modifier les contrôles d’accès au trousseau, autorisez uniquement les outils de signature nécessaires ; n’ouvrez pas l’accès à la clé privée à toutes les applications pour corriger une seule erreur. Pour ouvrir un ticket, fournissez uniquement le résultat expurgé de la vérification des identités, le code d’erreur et le type d’utilisateur d’exécution.
Ajoutez les mêmes vérifications d’environnement au job en échec au lieu de les exécuter uniquement dans le terminal SSH. Comparez l’utilisateur d’exécution, le répertoire développeur, la version de Xcode, le PATH et les simulateurs disponibles. Un processus de service ne charge pas forcément la configuration du shell interactif : une exécution manuelle réussie ne prouve donc pas que l’environnement du service est identique.
whoami
xcode-select -p
xcodebuild -version
printf '%s\n' "$PATH"
xcrun simctl list devices availableSi le simulateur voulu ne figure pas dans la liste, vérifiez d’abord que le runtime requis est installé et que la destination du test correspond. Si le runner apparaît hors ligne, vérifiez l’état du service et les journaux de tâches, puis la connexion réseau et les informations d’enregistrement. En l’absence de données de référence, validez d’abord le processus avec un seul build, puis augmentez progressivement le nombre de tâches parallèles en surveillant la mémoire unifiée et l’espace disque.
La location dédiée signifie que les ressources physiques ne sont pas partagées avec d’autres clients, mais plusieurs tâches sur un même nœud peuvent tout de même se gêner. Consultez le guide de connexion pour les instructions détaillées sur GitHub Actions et GitLab CI.
Tous les prix sont en dollars américains. Seuls USDT-TRC20 et les cartes Visa / Mastercard / Amex (via Stripe) sont acceptés. Les moyens réellement disponibles sont ceux affichés en temps réel dans la console.
L’envoi indiqué par le portefeuille, la confirmation sur la blockchain et la vérification de la commande sont trois étapes distinctes. Le délai de confirmation dépend du traitement sur la blockchain et du statut de la passerelle de paiement ; aucun délai fixe n’est indiqué sur cette page. Vérifiez d’abord le réseau, l’adresse du destinataire et le montant demandés sur la page de paiement, puis confirmez que la transaction a abouti et consultez enfin le statut de la commande dans la console.
Ne payez pas une seconde fois simplement parce que le statut de la commande n’a pas encore été actualisé. Pour demander une vérification manuelle, fournissez le numéro de commande, le hash de transaction, le montant et l’heure du transfert, avec le fuseau horaire. Le hash permet de retrouver la transaction ; votre phrase de récupération, la clé privée et le mot de passe du portefeuille ne sont ni nécessaires ni à transmettre. Si le réseau ou le montant utilisé ne correspond pas aux instructions de paiement, conservez l’historique de la transaction et indiquez-le clairement dans le ticket.
Consultez d’abord le message d’erreur affiché sur la page de paiement et le statut de la commande. Vérifiez ensuite auprès de votre banque si elle autorise cette transaction en dollars et si une authentification supplémentaire est nécessaire. Une autorisation en attente de la banque ne signifie pas forcément que la commande est payée ; ne vous fiez pas uniquement à la notification de votre carte pour confirmer la commande.
Après plusieurs échecs, demandez d’abord à votre banque la raison du refus et évitez de réessayer plusieurs fois rapidement. Si la console ne confirme toujours pas le paiement alors que le débit apparaît sur votre relevé, indiquez le numéro de commande, l’heure du paiement, le montant et le message d’erreur expurgé. Ajoutez également l’identifiant de transaction s’il est disponible. Ne communiquez jamais le numéro complet de votre carte, le cryptogramme ni les codes reçus par SMS. L’assistance vérifiera la commande et les données de paiement ; le statut du remboursement ou de la levée d’autorisation dépend également des résultats de la passerelle et de la banque émettrice.
Fiez-vous d’abord à la date d’expiration indiquée dans la console. Vérifiez-y l’heure d’envoi des rappels et le statut des notifications ; cette page ne garantit pas un nombre de jours précis avant l’échéance. Ne considérez pas non plus la réception d’un rappel comme le seul moyen de vérifier la continuité du service. Nous vous recommandons d’inscrire la date d’expiration dans le calendrier de l’équipe et de désigner une personne chargée de vérifier le renouvellement.
Après avoir choisi une période journalière, hebdomadaire, mensuelle ou trimestrielle, vérifiez le modèle, les options et la durée de location indiqués sur la facture de renouvellement. Une fois le paiement effectué, confirmez que la commande a bien été mise à jour au lieu de vous fier uniquement à une capture de la page de paiement. Sans renouvellement à l’échéance, l’accès au nœud sera affecté ; sauvegardez les projets, les livrables et les configurations nécessaires avant cette date. Si l’heure ou le montant affiché dans la console ne correspond pas à vos attentes, conservez le numéro de facture et ouvrez un ticket avant de décider de poursuivre le paiement.
Consultez la page des offres pour connaître le prix de chaque période complète et les frais d’extension de stockage. Pour toute question de facturation liée à une commande existante, demandez une vérification via un ticket dans la console ; ne joignez pas le mot de passe de la machine à un e-mail.
Essayez un mot plus court, comme « port », « signature » ou « paiement ». Vous pouvez aussi effacer la recherche pour afficher les 10 réponses. Si le problème persiste, ouvrez un ticket en joignant les résultats des vérifications.
Les clients disposant d’une location doivent passer par la console pour ouvrir un ticket. Les demandes sont traitées selon leur impact : les nœuds inaccessibles sont prioritaires, tandis que les problèmes de configuration et les questions de facturation sont orientés vers l’équipe concernée.
Les questions sur l’environnement de développement, la configuration et le renouvellement peuvent être traitées par ticket. Les échanges utilisent UTC+8 comme référence horaire et couvrent les heures ouvrées de la région Asie-Pacifique. Consultez les indications et les réponses du ticket dans la console pour connaître les horaires de réponse et l’avancement ; aucun délai fixe n’est garanti sur cette page.
Précisez l’opération souhaitée, le résultat obtenu et les étapes déjà essayées, puis ajoutez la commande minimale permettant de reproduire le problème. Si plusieurs personnes utilisent le nœud à tour de rôle, indiquez si des builds ou des sessions graphiques étaient exécutés en parallèle au moment du problème, afin de ne pas confondre un conflit de tâches avec une panne du nœud.
Si SSH et la connexion graphique échouent tous deux et que le nœud ne peut plus servir à une tâche en cours, indiquez « nœud inaccessible » dans l’objet et précisez la date et l’heure de la dernière connexion réussie. Ajoutez également le résultat du test de port effectué depuis un autre réseau pour aider à distinguer un problème de réseau local d’un problème côté nœud.
La priorité urgente sert à organiser le diagnostic et ne garantit pas un délai fixe de rétablissement. Si SSH reste accessible, précisez la fonctionnalité touchée. N’effacez pas le disque, ne réinstallez pas le système et ne coupez pas l’alimentation à répétition avant d’avoir signalé le problème : vous risqueriez d’aggraver la situation et de perdre des éléments utiles au diagnostic.
Indiquez le numéro de commande, le modèle et l’identifiant du nœud. Les nœuds disponibles sont à Singapour, Tokyo, Séoul et Hong Kong. N’envoyez ni mot de passe de la machine, ni clé privée SSH, ni informations de vérification de paiement.
Notez l’heure de début de l’incident et le fuseau horaire. Précisez s’il touche SSH, le bureau graphique, une tâche de build ou la vérification du paiement, ainsi que l’heure de la dernière utilisation normale.
Collez la sortie des commandes après en avoir supprimé les données sensibles, le code d’erreur et les étapes minimales pour reproduire le problème. Recadrez les captures d’écran pour retirer le contenu du projet et les identifiants. Pour un même problème, ajoutez de préférence les informations au ticket existant afin de conserver tout le contexte.
Si vous ne pouvez pas vous connecter à la console ou si vous avez une demande avant-vente, une question sur une location en volume ou un signalement de sécurité, écrivez à support@xcodenode.com. Ne joignez pas non plus à l’e-mail de mot de passe, de clé privée, d’élément de signature ni les informations complètes d’une carte bancaire.
Le guide de connexion couvre SSH, le bureau graphique et l’intégration CI. Pour toute demande qui ne concerne pas une commande, la page de contact vous indique les informations à fournir et le canal à utiliser.