Pour les nouveaux utilisateurs, les ingénieurs release et les responsables CI/CD. Saisissez une commande, un extrait d’erreur ou le nom d’une tâche pour cerner le problème, puis vérifiez chaque résultat attendu.
8 points d’accès affichés.
Chaque point d’accès indique les éléments à vérifier, les commandes ou les indicateurs à observer. Le filtrage modifie uniquement les points d’accès ci-dessous et ne masque aucune section complète.
Récupérez les informations de connexion dans la console et vérifiez SSH, l’interface graphique, le mot de passe et le fuseau horaire.
Vérifiez la chaîne d’outils Xcode, les éléments de signature, le chemin d’archive et les règles de conservation des artefacts de build.
Distinguez l’enregistrement sur la plateforme, les étiquettes du nœud, les limites de concurrence et le répertoire de travail de chaque tâche.
Écartez progressivement les causes de latence interactive : résolution, couleurs, fréquence d’images et instabilité réseau.
Harmonisez le sens de nœud, runner, cache et ressources de signature afin de réduire les ambiguïtés de collaboration.
Organisez les problèmes réseau, disque, Xcode et signature en commandes, résultats attendus et scénarios d’erreur.
Indiquez la région, l’heure, l’identifiant de la tâche et les logs expurgés pour permettre au support de reproduire le parcours.
Distinguez les caches reconstructibles, les résultats d’archivage et les artefacts de release à conserver impérativement.
Essayez de raccourcir le texte de l’erreur ou recherchez le nom d’une commande, par exemple xcodebuild et df -h et ping.
Fiez-vous aux informations de l’instance actuellement affichées dans la console. Ne copiez pas d’adresse ni d’identifiants depuis d’anciens tickets, messages ou scripts.
Établissez d’abord une connexion stable, puis vérifiez le mot de passe et le fuseau horaire. Ne changez pas simultanément le réseau, la résolution et le mode d’authentification : il serait difficile d’identifier la cause du changement.
Vérifiez la région du nœud, l’adresse de l’hôte, le port, le nom d’utilisateur et l’état de l’instance. Conservez les identifiants uniquement dans un gestionnaire de mots de passe contrôlé, jamais dans le dépôt de code ou les logs de build.
Exécutez ssh -v user@host pour afficher les étapes de résolution, de handshake et d’authentification. En cas d’expiration avant l’établissement de la connexion, vérifiez d’abord le réseau local et le port ; en cas d’échec d’authentification, contrôlez le nom d’utilisateur et les identifiants actuels.
Pour utiliser l’interface Xcode, employez VNC ou le partage d’écran. Conservez d’abord la résolution et les couleurs par défaut, puis ajustez la qualité après avoir vérifié le clavier, la souris et le presse-papiers.
Remplacez le mot de passe initial, exécutez date et systemsetup -gettimezone pour vérifier la date, l’heure et le fuseau horaire, puis confirmez que le répertoire du projet appartient à l’utilisateur de la tâche.
Un build iOS reproductible exige une chaîne d’outils, un point d’entrée du projet, des ressources de signature, des paramètres d’archivage et un emplacement d’export fixes. Noter simplement « échec du build » ne suffit pas pour effectuer une vérification.
Exécutez d’abord xcode-select -p et xcodebuild -versionpour confirmer le répertoire développeur et la version de Xcode réellement utilisés par le script. Après un changement de version, relancez ces deux commandes ; ne vous fiez pas au titre de la fenêtre du terminal.
Limitez l’accès aux ressources de signature selon le projet et l’environnement. Après l’import, utilisez security find-identity -v -p codesigning pour vérifier les identités disponibles ; n’affichez jamais le mot de passe du certificat dans les logs du pipeline.
Le script doit spécifier explicitement le workspace ou project, le scheme partagé, la configuration et -archivePath. Sur la machine de build, ne dépendez pas de la sélection temporaire effectuée lors de la précédente utilisation de l’interface Xcode.
Générez les artefacts avec -exportArchive et une configuration d’export versionnée. Conservez l’archive, le résultat d’export, les logs de build et l’identifiant du commit ; même en cas d’échec, gardez les informations de diagnostic expurgées.
xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-archivePath "$PWD/output/App.xcarchive" \
clean archiveLes nœuds OakVM sont des machines physiques dédiées, et non des machines virtuelles. La concurrence s’étend en ajoutant des nœuds dédiés ; sur un même nœud, définissez clairement la file d’attente, les étiquettes et les limites des répertoires de travail.
runs-on ; n’utilisez pas d’étiquettes génériques au sens ambigu.Base d’isolation :Gérez séparément le répertoire du projet, le cache de build, les ressources de signature et le répertoire des artefacts. N’effacez pas l’intégralité du nœud comme méthode d’isolation courante et ne faites pas partager à deux projets le même ensemble de répertoires de signature inscriptibles.
La sensation de lenteur dans VNC et le partage d’écran ne provient pas forcément de la charge de calcul du nœud. Effectuez les tests dans un ordre fixe pour distinguer la pression d’encodage, les fluctuations du réseau local et la concurrence des tâches en arrière-plan.
Réduisez d’abord la résolution d’affichage au niveau minimal nécessaire à l’opération en cours et désactivez les zones d’affichage supplémentaires inutilisées. Si la réactivité s’améliore nettement, le problème est probablement lié au volume d’encodage de l’image.
Mettez en pause les vidéos, les aperçus animés et les fenêtres de supervision constamment actualisées. Pendant le build, désactivez les écrans d’émulateur inutiles et vérifiez si les opérations d’édition statiques redeviennent stables.
L’édition de code et les opérations de release ne nécessitent généralement pas une fréquence d’images élevée. Visez d’abord la réactivité de la saisie et la lisibilité du texte, puis augmentez progressivement la fluidité.
Effectuez un test continu de faible latence vers l’adresse du nœud ; surveillez les variations et les pertes de paquets, pas uniquement la valeur minimale ponctuelle. Après avoir changé de réseau local, répétez le test avec le même nombre d’échantillons.
Une seule personne doit piloter principalement chaque tâche ; les autres membres collaborent via les logs de build et les enregistrements d’artefacts. Les manipulations simultanées de l’interface graphique augmentent les conflits de contexte.
Les termes suivants sont utilisés sur les pages OakVM, dans la console et lors des échanges avec le support. Ils décrivent le mode de livraison et le workflow, sans constituer une recommandation de plateformes tierces.
Conservez d’abord le code de sortie brut et la première erreur pertinente avant toute correction. Exécuter plusieurs commandes de nettoyage successives peut faire disparaître le contexte du problème et conduire à prendre une erreur de dépendance pour une panne du nœud.
| Élément vérifié | Commande ou action | Résultat attendu | Scénario d’erreur |
|---|---|---|---|
| Résolution réseau et accessibilité | ping -c 20 hostssh -v user@host |
Résolution d’adresse cohérente ; aucune perte persistante dans l’échantillon ; SSH atteint les étapes de handshake et d’authentification. | En cas d’erreur de résolution, vérifiez l’adresse ; en cas d’expiration avant la connexion, changez de liaison locale et retestez ; en cas d’échec d’authentification, vérifiez uniquement le nom d’utilisateur et les identifiants actuels. |
| Disque et espace de build | df -hdu -sh ~/Library/Developer/Xcode/DerivedData |
Le volume cible dispose de suffisamment d’espace pour le code source, les dépendances, l’archive et le résultat d’export ; la taille du cache reste sous le seuil de l’équipe. | Déplacez d’abord les artefacts à conserver, puis supprimez les caches reconstructibles du projet ; ne supprimez pas directement une archive dont l’appartenance n’est pas certaine. |
| Chaîne d’outils Xcode | xcode-select -pxcodebuild -version |
Le répertoire développeur et la version correspondent aux informations du pipeline ; les commandes s’exécutent correctement. | En cas d’erreur de chemin, sélectionnez explicitement la chaîne d’outils ; si la version ne correspond pas, arrêtez la tâche pour éviter de générer des archives incomparables. |
| Projet et scheme | xcodebuild -list -workspace App.xcworkspace |
Le scheme cible est visible et le scheme utilisé pour l’automatisation est partagé. | Si la liste est vide, vérifiez le répertoire de travail et la génération des dépendances ; si le scheme est invisible, contrôlez le partage du projet et la casse de son nom. |
| Identité de signature | security find-identity -v -p codesigning |
L’identité de signature requise par la tâche est visible ; la sortie ne contient aucune ambiguïté due à des identités expirées ou à des doublons. | Si l’identité manque, vérifiez le périmètre d’import, l’accès au trousseau et la correspondance avec le profil ; ne publiez jamais de clé privée ni de mot de passe. |
| Archivage et export | Conserver xcodebuild : code de sortie, chemin d’archive et logs d’export. |
Le répertoire d’archive existe et le résultat d’export correspond à l’identifiant du commit et au numéro de tâche. | Commencez le diagnostic au premier error du log ; distinguez les phases de compilation, signature, archivage et export, sans résumer tout l’échec par la dernière ligne. |
Après avoir changé de réseau, conservez les paramètres d’affichage ; après avoir changé de Xcode, conservez le même commit source. Vous pourrez ainsi comparer les résultats.
Les erreurs suivantes sont souvent des conséquences en chaîne. Notez le premier bloc d’erreur, le code de sortie et la commande correspondante.
Supprimez les identifiants de l’hôte, les jetons, le contenu des clés privées et les chemins sensibles du projet, tout en conservant l’heure, le numéro de tâche et les versions des outils.
Les utilisateurs existants peuvent se connecter à la console pour envoyer un ticket ; s’ils ne peuvent pas se connecter, écrivez à support@oakvm.com. Dans les deux cas, ne collez jamais d’identifiants de connexion sur une page publique.
Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong, est des États-Unis ou ouest des États-Unis.
Indiquez la date, l’heure et le fuseau horaire afin d’aligner les logs du nœud.
Fournissez un identifiant permettant de retrouver la commande, l’instance ou la tâche CI.
Énumérez le point d’accès, les commandes et la dernière étape réussie avant l’apparition du problème.
Décrivez séparément les résultats attendu et réel ; n’écrivez pas seulement « impossible à utiliser ».
Conservez le contexte de l’erreur, le code de sortie et les versions ; supprimez les identifiants, jetons et clés privées.
Choisissez OakVM M4 ou OakVM M4 Pro et configurez la durée de location dans six régions de nœuds disponibles. Toutes les régions fonctionnent 365 jours par an ; la disponibilité réelle est celle renvoyée en temps réel par la console.