Connexion · Migration · CI/CD

Résoudre un problème : de la vérification de connexion au rétablissement du pipeline

Commencez par identifier la couche concernée, puis réunissez le nœud, l’horodatage, l’erreur complète et la dernière modification. Voici une séquence de vérifications directement applicable aux interfaces graphiques, à la ligne de commande, à Xcode et aux Runners auto-hébergés des Mac cloud ArmMacs.

diagnostic-checklist

01 identifier le nœud et le modèle

02 relever l’état du réseau local

03 reproduire une fois avec horodatage

04 recueillir les journaux désensibilisés

05 joindre les éléments au ticket

Interface graphique et ligne de commande entièrement disponibles Nœud physique dédié, pas une machine virtuelle Fonctionnement continu 365 jours par an

Routage de l’assistance

Commencez par orienter le problème

Un même symptôme peut venir du réseau local, du système du nœud, de la chaîne d’outils ou de la configuration du pipeline. Choisissez d’abord la catégorie la plus proche et notez le nœud concerné, l’heure locale et le fuseau, le message d’erreur exact ainsi que la dernière heure de réussite.

Conservez le message d’erreur exact ; n’écrivez pas seulement « impossible à utiliser ». Avant d’envoyer les journaux, supprimez les mots de passe, clés privées, jetons d’accès, contenus liés à la signature et données métier des dépôts.

Première connexion

Effectuez la première connexion en quatre étapes

Ne modifiez pas simultanément le réseau, les identifiants et les réglages système. Validez le résultat après chaque étape afin d’identifier précisément l’origine du problème.

  1. 01

    Récupérer et vérifier les identifiants

    Ouvrez la commande correspondante dans la console et vérifiez le modèle, le nœud, l’adresse de connexion, le nom d’utilisateur, le mot de passe temporaire ou les identifiants SSH. Vérifiez que vous consultez bien l’instance cible, et non une commande terminée ou située dans une autre région. Conservez les identifiants uniquement dans un gestionnaire de mots de passe contrôlé.

  2. 02

    Vérifier le réseau local vers le nœud

    Notez d’abord le type de réseau local, l’environnement de sortie et l’heure du test, puis vérifiez la résolution DNS, l’accessibilité de la cible et les ports requis. Si le réseau de l’entreprise échoue tandis qu’un réseau de secours fonctionne, vérifiez en priorité le pare-feu local, le proxy ou la politique de sortie ; ne réinitialisez pas le nœud à répétition.

  3. 03

    Établir une connexion VNC ou SSH

    Utilisez le bureau distant VNC pour l’interface graphique ; privilégiez SSH pour exécuter des scripts, synchroniser un dépôt ou intégrer l’automatisation. Lors de la première connexion, commencez par une courte session pour vérifier la saisie clavier, la lecture-écriture de fichiers et l’exécution des commandes avant de migrer de gros volumes de données ou d’installer des dépendances.

  4. 04

    Modifier les réglages de sécurité initiaux

    Remplacez immédiatement le mot de passe temporaire, configurez la clé publique SSH selon les règles de l’équipe, limitez la visibilité des identifiants et vérifiez les paramètres d’accès distant. N’inscrivez pas de clé privée, de phrase secrète de certificat ou de jeton de pipeline dans des scripts partagés, des journaux de compilation ou des fichiers de dépôt.

Éléments de preuve de connexion

Informations minimales à relever en cas d’échec de connexion

node: SG / JP / KR / HK / US-W
protocol: VNC or SSH
local_network: office / home / mobile
timestamp: YYYY-MM-DD HH:MM timezone
result: timeout / refused / authentication failed
last_success: YYYY-MM-DD HH:MM timezone

Parcours de migration

Du Mac local à un pipeline reproductible

Migrer ne signifie pas copier tout le répertoire utilisateur. Traitez séparément les données du projet, la définition de la chaîne d’outils et la configuration du Runner afin de limiter la dérive d’environnement et de faciliter l’export complet avant la fin de la période de location.

PARCOURS 01

Migrer les données du projet

  1. Définir le périmètreMigrez uniquement les dépôts, jeux de données nécessaires, modèles de configuration et entrées de compilation ; ne copiez pas les caches sans rapport.
  2. Calculer le volumeRelevez la taille du répertoire source, le nombre de fichiers et les sommes de contrôle, en prévoyant l’espace nécessaire aux dépendances et aux artefacts de compilation.
  3. Transférer par lotsPour les petits dépôts, vérifiez d’abord les droits et le format des fins de ligne. Pour les gros volumes, séparez les répertoires et effectuez des contrôles ponctuels après le transfert.
  4. Isoler les secretsConfigurez séparément les identifiants sensibles par un moyen contrôlé ; ne les placez ni dans une archive, ni dans un dépôt, ni dans un répertoire de synchronisation standard.
PARCOURS 02

Reproduire Xcode et les dépendances

  1. Figer les versionsNotez les versions de Xcode, des outils en ligne de commande, du runtime du langage et du gestionnaire de paquets.
  2. Restaurer les dépendancesPrivilégiez les fichiers de verrouillage et les scripts d’installation exécutables ; ne copiez pas directement le cache de compilation local.
  3. Exécuter la compilation de référenceLancez d’abord la cible minimale, puis les tests et l’archivage complet ; conservez séparément les codes de sortie et les journaux.
  4. Formaliser la checklistInscrivez les versions, l’ordre d’installation, les noms des variables d’environnement et les commandes de validation dans le manuel d’exploitation de l’équipe.
PARCOURS 03

Intégrer un Runner CI/CD

  1. Créer un environnement d’exécution dédiéSéparez les tâches du pipeline des opérations quotidiennes sur le bureau distant afin de réduire les conflits de droits et de répertoires.
  2. Définir des étiquettes précisesLes étiquettes doivent au minimum indiquer la plateforme, le niveau de puce et la version majeure de Xcode afin d’éviter l’affectation d’une tâche au mauvais nœud.
  3. Commencer avec une seule exécution simultanéeValidez d’abord la compilation, les tests, l’archivage et le retour des artefacts, puis évaluez le besoin de parallélisme.
  4. Définir le nettoyageÀ la fin de chaque tâche, supprimez les identifiants temporaires, les données dérivées et les artefacts inutiles, tout en conservant les journaux nécessaires.

Diagnostics Xcode

Diagnostiquer la compilation Xcode dans le cloud par couches

Vérifiez d’abord la chaîne d’outils, puis les droits, le cache et le stockage. Ne mettez pas simultanément Xcode à niveau, les dépendances à jour et les fichiers de signature à jour lors d’une même nouvelle tentative : les journaux ne permettraient plus d’identifier la modification efficace.

Couche à vérifier Faits à contrôler Action recommandée Éléments à joindre au ticket
Sélection de version La version graphique de Xcode, le chemin des outils en ligne de commande et le SDK requis par le projet sont-ils cohérents ? Figez une version pour effectuer une compilation minimale et vérifiez que le pipeline et le terminal interactif utilisent le même chemin. Sortie de version, chemin sélectionné, cible en échec
Fichiers de signature Les fichiers sont-ils complets, valides et correctement référencés par la cible et la configuration ? Vérifiez leur lisibilité dans un environnement isolé sans écrire de contenu sensible dans les journaux. Noms désensibilisés, période de validité, erreur exacte
Droits sur les certificats L’utilisateur qui exécute la compilation peut-il accéder aux certificats et éléments de clé requis ? Comparez l’environnement de droits de la compilation interactive et celui de l’utilisateur du Runner afin de réduire les écarts. Utilisateur d’exécution, résultat des droits, étape en échec
Derived Data L’ancien cache provient-il d’une autre branche, version de Xcode ou configuration de compilation ? Après avoir sauvegardé un journal d’échec, nettoyez le cache cible puis exécutez la même commande à titre de comparaison. Différences de codes de sortie et de journaux avant et après nettoyage
Espace disque Espace restant sur le volume système, répertoire d’archives, données des simulateurs et cache des dépendances Supprimez d’abord les caches régénérables et les artefacts obsolètes ; ne supprimez pas l’unique copie. Espace restant avant l’échec et répertoire le plus volumineux
Journaux de compilation La première erreur réelle, la cible en échec, le code de sortie et le contexte sont-ils complets ? Conservez le journal texte original, extrayez les lignes autour de la première erreur et désensibilisez-les. Commande, horodatage, code de sortie, pièce jointe de journal

Les journaux doivent uniquement conserver le contexte nécessaire au diagnostic. Avant l’envoi, recherchez et supprimez les jetons, mots de passe, clés privées, phrases secrètes de certificats, adresses de dépôts internes et données métier.

Manuel du Runner

Bases d’intégration et de nettoyage des deux types de Runner

ArmMacs fournit des nœuds physiques dédiés : les répertoires de tâches et la chaîne d’outils peuvent donc être conservés d’une compilation à l’autre. Cette persistance signifie aussi que les caches, identifiants et anciens artefacts ne disparaissent pas automatiquement ; définissez clairement les limites du nettoyage dans le pipeline.

GitHub Actions

Runner Mac auto-hébergé

  1. EnregistrementEffectuez l’enregistrement avec une identité Runner dédiée, vérifiez qu’il reste affiché en ligne après le démarrage du service, puis notez son nom et son répertoire de travail.
  2. ÉtiquettesConservez l’étiquette de plateforme et ajoutez le niveau de puce, la version majeure de Xcode et l’usage. Les workflows doivent uniquement correspondre aux combinaisons d’étiquettes réellement nécessaires.
  3. ConcurrenceCommencez par une exécution séquentielle, tâche par tâche. Plusieurs archivages Xcode simultanés se disputent le disque, le cache et les ressources de signature, ce qui augmente les échecs intermittents.
  4. NettoyageSupprimez les identifiants temporaires et les fichiers propres à la tâche après chaque exécution ; conservez le cache selon sa clé et sa limite de capacité, puis supprimez les copies locales obsolètes après le retour réussi de l’archive.
GitLab CI

Runner macOS

  1. EnregistrementDéfinissez le périmètre d’appartenance et le mode d’exécution du Runner, vérifiez les droits du répertoire de l’utilisateur de compilation, puis conservez l’heure d’enregistrement et un résumé de configuration.
  2. ÉtiquettesDéfinissez des étiquettes pour macOS, le niveau de puce, la version majeure de Xcode et le type de tâche ; empêchez les tâches sans étiquette d’utiliser par erreur le nœud dédié.
  3. ConcurrenceDéfinissez initialement la concurrence sur 1. N’envisagez de l’augmenter qu’après isolation complète des répertoires de tâches, ports, caches et éléments de signature.
  4. NettoyageÀ la fin de la tâche, nettoyez les fichiers secrets et artefacts temporaires du répertoire de travail ; nettoyez également les tâches en échec et conservez séparément les journaux désensibilisés.

Matrice minimale de validation avant mise en production

checkout ✓ restauration des dépendances ✓ compilation ✓ tests ✓ export des artefacts ✓ nettoyage des secrets ✓

Bureau distant

Pour le bureau distant, distinguez d’abord l’affichage, la saisie et la session

L’expérience VNC dépend à la fois du réseau local, du chemin interrégional, de la résolution et de la fréquence des changements à l’écran. En cas de problème, notez d’abord le nœud et l’état du réseau local, puis ne modifiez qu’une variable pour comparer.

Que faire en cas de latence d’affichage ou de défilement saccadé ?

Notez le nœud, le type de réseau local, l’heure du test et la présence éventuelle d’un proxy. Réduisez d’abord la résolution et la qualité du bureau distant, désactivez les animations ou vidéos en mouvement continu, puis comparez le retour de saisie. Si un réseau de secours améliore nettement la situation, vérifiez la congestion ou la politique de sortie locale ; si plusieurs réseaux présentent le même résultat au même moment, transmettez le nœud et l’horodatage.

Que faire si la résolution ou la mise à l’échelle de l’interface est incorrecte ?

Commencez par configurer une résolution courante sur un seul écran, déconnectez-vous puis rétablissez la session. Vérifiez que le mode de mise à l’échelle du client et les réglages d’affichage distants ne sont pas activés simultanément. Pour enregistrer le problème, conservez également la taille de la fenêtre cliente et la résolution distante.

Que faire si les raccourcis ou symboles saisis diffèrent ?

Vérifiez la disposition du clavier local et distant, puis testez les lettres, chiffres, symboles et combinaisons de touches dans un éditeur de texte brut. Si le problème ne concerne qu’une application, notez son nom et le raccourci ; s’il concerne toutes les applications, joignez les dispositions des deux côtés et la version du client.

Faut-il redémarrer immédiatement le nœud après une interruption de session ?

Ne redémarrez pas immédiatement. Vérifiez d’abord si le réseau local a changé, si l’appareil est passé en veille, si VNC est déconnecté alors que SSH reste accessible, et notez l’heure de l’interruption. Si SSH est accessible, sauvegardez d’abord l’état du travail et les journaux associés ; si les deux protocoles sont inaccessibles, ouvrez un ticket depuis la console.

Quelles informations conserver avant de se reconnecter ?

Conservez le nœud, le protocole, le réseau local, la version du client, la dernière heure de réussite, l’heure de l’interruption et l’erreur exacte. Lors de la reconnexion, ne modifiez qu’une condition, par exemple le réseau ou la résolution, et notez le résultat pour préserver la comparaison.

Responsabilité du stockage

Stockage, sauvegarde et export avant la fin de la période de location

Le répertoire de travail d’un nœud physique convient aux compilations et aux essais, mais ne doit pas être l’unique copie du code, des certificats, des modèles ou des artefacts. L’équipe utilisatrice doit intégrer la migration, les sauvegardes externes et l’export final au plan du projet.

01

Classer les données avant migration

Répartissez les données en quatre catégories : récupérables depuis le dépôt, recréables depuis les sources de dépendances, à sauvegarder impérativement et interdites de téléversement. Estimez la capacité maximale du projet, des dépendances, de Derived Data, des archives et des journaux ; ne vous limitez pas à la taille du code source.

02

Créer une sauvegarde externe indépendante

Conservez le code critique, les certificats, les modèles, les jeux de données et les artefacts finaux dans un emplacement de sauvegarde externe contrôlé par l’équipe. Effectuez régulièrement des tests de restauration pour vérifier que la sauvegarde contient des données utilisables, pas seulement une liste de fichiers.

03

Gérer les identifiants sensibles

Configurez les identifiants avec le minimum de droits nécessaires et séparez les usages manuels de ceux du pipeline. Ne les inscrivez ni dans l’historique shell, ni dans le dépôt, ni dans des fichiers d’environnement ordinaires, ni dans les artefacts de compilation ; supprimez rapidement les anciennes copies après rotation.

04

Limiter la croissance du cache

Définissez des règles de conservation pour le cache des dépendances, Derived Data, les données des simulateurs et les archives. Vérifiez avant suppression que le contenu est recréable ; en cas de manque d’espace, traitez en priorité les caches obsolètes et les artefacts déjà transférés.

Avant expiration

Checklist avant la fin de la période de location

  • Exporter le code non poussé, les jeux de données, les modèles, les archives et les résultats de tests
  • Vérifier le nombre de fichiers, la taille et les principales sommes de contrôle de la copie externe
  • Arrêter le Runner et retirer le nœud d’exécution correspondant du pipeline
  • Révoquer les jetons, l’autorisation des clés SSH et les identifiants d’accès temporaires
  • Supprimer du nœud les données métier, fichiers secrets et journaux devenus inutiles
  • Vérifier dans la console la période de location, l’état du renouvellement et la date de fin de la commande

Ticket d’assistance

Ouvrir un ticket directement reproductible

En cas de panne du nœud loué, connectez-vous en priorité à la console pour ouvrir un ticket. La console associe le problème à la commande afin de faciliter la vérification du modèle, du nœud et de l’état de livraison. Si vous ne pouvez pas accéder à la console, envoyez un e-mail à support@armmacs.com.

ticket-evidence.txt
Numéro de commande :
Modèle :
Nœud :
Type de problème :
Date, heure et fuseau :
Dernière réussite :
Étapes de reproduction :
Résultat attendu :
Résultat obtenu :
Erreur exacte :
Dernière modification de configuration :
État du réseau local :
Pièces jointes : journaux désensibilisés / captures d’écran

Rendre les étapes de reproduction exécutables

Décrivez dans l’ordre réel le mode de connexion, les commandes exécutées, le projet cible et l’étape en échec. Si le problème n’apparaît pas à chaque fois, indiquez sa fréquence et les conditions de comparaison déjà vérifiées.

Toujours inclure le fuseau dans l’horodatage

Utilisez la date complète, l’heure, les minutes et le fuseau horaire. Écrire uniquement « tout à l’heure » ou « aujourd’hui » ne permet pas de faire correspondre précisément l’événement avec le nœud et les journaux du Runner.

Désensibiliser les pièces jointes avant envoi

Les captures d’écran et journaux ne doivent contenir ni mots de passe, ni clés privées, ni jetons, ni phrases secrètes de certificats, ni données métier. Conservez uniquement l’erreur exacte, le code de sortie et le contexte nécessaire.

Prêt pour le diagnostic

Nœud, horodatage et journaux sont prêts

Connectez-vous à la console, associez la commande et ouvrez un ticket. La facturation se fait uniquement en dollars ; les paiements acceptés sont USDT-TRC20 et Visa / Mastercard / Amex (via Stripe). Les moyens réellement disponibles sont ceux indiqués par la console.