Commencez par déterminer si le problème concerne la connexion, l’environnement de développement, le CI/CD, le stockage, le réseau ou la gestion de compte, puis vérifiez méthodiquement l’état, les paramètres et les journaux. Oakmini fournit des Mac mini physiques dédiés, et non des machines virtuelles. Lors du diagnostic, vérifiez séparément les conditions de connexion locales, l’état du nœud et la chaîne d’outils du projet.
$ uname -m
arm64
$ sw_vers -productVersion
macOS ready
$ ssh -v oak-node
debug1: Authentication succeeded
$ df -h /
Filesystem status: availableNe modifiez pas simultanément le réseau, les identifiants et les versions des outils. Sélectionnez d’abord le symptôme le plus proche, vérifiez une seule variable à la fois et notez l’heure, l’action effectuée et le résultat. Vous éviterez ainsi qu’une modification n’en masque une autre.
Pour les délais d’attente SSH, écran noir VNC, identifiants refusés ou déconnexions immédiates.
Commencer par vérifier l’état de l’hôtePour les problèmes de chemin Xcode, de paquets Homebrew, de configuration Git, de Fastlane ou de version du runtime.
Vérifier les chemins et les versionsPour les runners hors ligne, les étiquettes incompatibles, les tâches en attente, les caches défaillants ou les artefacts de build incomplets.
Commencer par l’état d’enregistrement du runnerPour l’espace disque insuffisant, les caches qui grossissent, les répertoires de travail désordonnés ou les artefacts impossibles à exporter.
Vérifier la capacité, les répertoires et l’utilisationPour la latence interactive élevée, les pertes de paquets intermittentes, les transferts lents ou l’accès impossible depuis un réseau local précis.
Comparer les connexions et les plages horairesPour l’identification d’une commande, les droits d’administration de l’hôte, le statut de renouvellement ou l’absence de mise à jour d’une opération dans la console.
Commencer par vérifier la commande et l’historique des opérationsUtilisez df -h pour afficher la capacité du volume, puis utilisez du -sh pour vérifier les projets, les caches de build et les répertoires d’exportation. Avant toute suppression, vérifiez que les artefacts sont sauvegardés et ne videz jamais directement un répertoire système inconnu.
Notez séparément le temps d’établissement SSH, les opérations VNC, la récupération du code et le build local. Si seule l’interface graphique est lente, ajustez d’abord la qualité VNC. Si la ligne de commande et les transferts sont également perturbés, vérifiez la connexion locale et l’accessibilité du nœud.
Vérifiez le compte actuellement connecté, l’identifiant de commande, la région sélectionnée et l’heure de la dernière opération. L’état de l’hôte, les commandes et les actions d’administration se gèrent dans la console. Dans une demande d’assistance, fournissez uniquement l’identifiant de commande, jamais vos identifiants de connexion.
Une connexion peut échouer au niveau de l’état de l’hôte, du réseau local, des paramètres de connexion, du pare-feu ou des identifiants. Vérifiez chaque couche dans l’ordre et ne modifiez pas la suivante avant d’avoir validé la précédente.
Vérifiez que le Mac cloud associé à la commande est accessible et que la région du nœud ainsi que les informations de connexion correspondent au même nœud physique. Après une opération d’administration, notez l’heure et l’état actuels et ne soumettez pas plusieurs fois la même action.
Critère de réussite : l’hôte est opérationnel et l’identifiant de commande, la région du nœud et la cible de connexion correspondent.Vérifiez d’abord que le réseau local peut atteindre l’adresse et le port cibles, puis comparez avec un autre réseau fiable. Si seul le réseau professionnel échoue, vérifiez la politique de sortie. Si tous les réseaux échouent, conservez l’heure du test, le port cible et le type d’erreur.
nc -vz HOST PORT
ssh -vvv USER@HOSTVérifiez que l’adresse de l’hôte, le port, le nom d’utilisateur et le mode de connexion proviennent de la commande actuelle. Un alias de configuration SSH peut remplacer le port ou le chemin de la clé ; utilisez les journaux détaillés pour voir les paramètres réellement utilisés. Avec VNC, vérifiez l’adresse cible, les réglages d’affichage et les anciennes données enregistrées par le client.
ssh -G oak-node
ssh -v USER@HOST -p PORTAvant un test temporaire, notez les règles existantes. Vérifiez que le terminal, le client SSH ou le client VNC peut établir la connexion et que le réseau d’entreprise n’interdit pas le port cible. Ne désactivez pas durablement toute la protection locale pour diagnostiquer un problème.
Critère de réussite : le programme cible dispose d’une autorisation de sortie explicite sur le port concerné et les tests réalisés sur un autre réseau donnent le même résultat.Distinguez le « délai d’attente réseau » du « refus d’authentification ». Le premier ne se résout pas en changeant le mot de passe ; pour le second, vérifiez le nom d’utilisateur, le fichier de clé, ses permissions et les éventuelles modifications récentes des identifiants. Une demande d’assistance ne doit contenir que le texte de l’erreur d’authentification, jamais un mot de passe ni une clé privée.
chmod 600 ~/.ssh/id_ed25519
ssh-add -l« Installé » ne signifie pas « utilisé par le pipeline ». Le diagnostic de la chaîne d’outils doit enregistrer le chemin des exécutables, les versions, l’environnement shell actuel et le résultat réel de l’appel par le projet.
| Outil | À vérifier en premier | Commande recommandée | Écart fréquent |
|---|---|---|---|
| Xcode | Répertoire développeur actuel, version et liste des SDK | xcode-select -pxcodebuild -version |
La ligne de commande pointe vers une autre version de Xcode ou le SDK requis par le projet n’est pas disponible |
| Homebrew | Chemin des binaires, liste des logiciels et résultat du diagnostic | brew --prefixbrew doctor |
Le shell ne charge pas le bon chemin ou la liste des paquets diffère de l’environnement local après une migration |
| Git | Version, URL distante, droits du dépôt et configuration utilisateur | git --versiongit remote -v |
Le runner et le shell interactif utilisent des identifiants ou des répertoires de travail différents |
| Fastlane | Origine de l’appel, verrouillage des dépendances, lane et noms des variables d’environnement | bundle exec fastlane --version |
La version globale est appelée directement au lieu d’utiliser les dépendances du projet |
| Runtime du langage | Chemin de l’interpréteur, gestionnaire de versions et version verrouillée par le projet | which rubywhich node |
Le shell interactif et la tâche non interactive chargent des fichiers d’initialisation différents |
Notez la version de macOS, l’architecture de la puce, la version de Xcode, la liste des logiciels Homebrew, la version de Git et les runtimes utilisés. Ne modifiez qu’un composant majeur à la fois et sauvegardez la liste avant et après chaque mise à niveau.
Si une commande fonctionne dans le terminal local mais échoue dans le runner, ajoutez echo "$PATH",which et les commandes de version à une étape de diagnostic temporaire. Après vérification, supprimez les sorties d’environnement inutiles afin d’éviter d’exposer des variables sensibles dans les journaux.
Commencez par résoudre les dépendances, exécutez ensuite un build propre, puis vérifiez le chemin des artefacts et le code de sortie. Si le projet minimal réussit mais que le projet métier échoue, poursuivez avec la configuration du projet, le verrouillage des dépendances et les permissions des scripts.
La sortie ci-dessous suffit à établir une référence des versions. Avant d’envoyer une demande d’assistance, supprimez des répertoires le nom du projet et tout paramètre sensible.
uname -m
sw_vers
xcode-select -p
xcodebuild -version
brew --prefix
git --version
which ruby
which node
df -h /Les problèmes CI/CD se vérifient par niveaux : la tâche est-elle prise en charge, le répertoire de travail est-il accessible, les permissions sont-elles suffisantes, les dépendances sont-elles disponibles et le build se termine-t-il ? Ne concluez pas uniquement à partir du message d’échec final.
Vérifiez que le service du runner fonctionne, que son enregistrement est toujours valide et que la console l’affiche en ligne. Avant tout redémarrage, notez la dernière heure en ligne et la dernière tâche réussie.
Si une tâche reste longtemps en attente alors que le runner est en ligne, comparez les étiquettes requises par la tâche avec celles du runner. Des différences de casse, d’espaces ou d’architecture peuvent empêcher la prise en charge de la tâche.
Vérifiez que l’utilisateur du runner dispose des permissions nécessaires sur les répertoires du dépôt, du cache et des artefacts. N’élargissez pas les permissions de tous les répertoires pour masquer une erreur de configuration sur un seul chemin.
Lorsque le cache semble invalide, effectuez d’abord une tâche de comparaison sans lire l’ancien cache. Si des tâches concurrentes écrasent les mêmes fichiers, attribuez un répertoire de travail distinct à chaque tâche et vérifiez que la mémoire et le stockage d’Oak Core ou d’Oak Forge correspondent à la charge.
Conservez l’heure de début, le nom du runner, l’identifiant du commit, les versions clés des outils, l’étape en échec, le code de sortie et la fin du journal. Si l’échec est reproductible, notez les étapes minimales ; s’il est intermittent, conservez au moins une comparaison entre une réussite et un échec.
Vérifiez en priorité l’état en ligne du runner, l’autorisation du projet et les étiquettes. Ne nettoyez pas encore le cache : la tâche n’a pas commencé le build.
Vérifiez en priorité le répertoire de travail, les permissions des scripts, l’initialisation du shell et les chemins des outils. Comparez les variables d’environnement du terminal interactif et du runner.
Vérifiez les fichiers de verrouillage, les clés de cache, l’espace disque disponible et les journaux de téléchargement réseau. Utilisez une tâche avec cache propre pour comparaison et ne remplacez pas continuellement les preuves originales.
Vérifiez l’utilisation de la mémoire, les conflits d’écriture dans les répertoires partagés, les ports occupés et les noms des fichiers temporaires. Réduisez d’abord la concurrence pour confirmer le diagnostic avant de modifier le découpage ou la configuration des tâches.
L’emploi d’une terminologie cohérente réduit les échanges de clarification. Décrivez si possible l’objet précis, par exemple « délai d’attente SSH sur le nœud de Tokyo », plutôt que « le serveur est indisponible ».
Oakmini propose deux canaux de contact : ouvrez un ticket depuis la console ou envoyez un e-mail à support@oakmini.com. Pour une commande existante, l’état de l’hôte et le suivi d’un diagnostic en cours, privilégiez le ticket. Pour les demandes avant-vente ou si la console est inaccessible, utilisez l’e-mail.
Remplissez chaque point ; pour un élément inconnu, écrivez « non confirmé » au lieu de supposer. Si le problème comporte plusieurs tentatives, listez-les dans l’ordre chronologique.
Objet : identifiant de commande / catégorie du problème / région du nœud
Date, heure et fuseau horaire :
Méthode de connexion ou type de tâche :
Résultat attendu :
Résultat obtenu :
Étapes de reproduction :
1.
2.
3.
Diagnostic déjà effectué :
Texte exact de l’erreur et code de sortie :
Description des journaux désensibilisés joints :La page d’assistance fournit l’ordre du diagnostic, les commandes et les méthodes de préparation des informations. Les commandes, renouvellements, consultations de commandes, vérifications de l’état de l’hôte et opérations d’administration du Mac cloud s’effectuent dans la console. Tous les nœuds fonctionnent normalement 365 jours par an, avec une disponibilité continue. Si l’état affiché ne correspond pas au résultat réel de la connexion, notez l’heure et ouvrez un ticket.