De la connexion à la validation des artefacts

Intégrez un Mac dans le cloud à votre pipeline de build

Il ne s’agit pas d’une présentation théorique, mais d’un parcours opérationnel à suivre étape par étape. Vérifiez d’abord l’identité et sécurisez le Mac physique dédié, puis préparez Xcode, les éléments de signature et les tâches automatisées. En cas d’anomalie, recueillez les sorties réseau et les journaux de build selon un format cohérent.

5 catégories Thèmes pris en charge
6 étapes Chaîne de packaging automatisée
2 options Canaux de contact traçables
Louer un Mac dans le cloud Voir la configuration Runner M4
PARCOURS D’ASSISTANCE RUNNER MAC-01
01
Réception et vérification Paramètres de connexion, empreinte de l’hôte, mot de passe initial
Préparer
02
Préparer l’environnement de build Xcode, chaîne d’outils, éléments de signature, répertoires
Configurer
03
Exécuter les tâches automatisées Checkout, cache, archivage, export, validation
Exécuter
04
Rassembler les éléments de diagnostic Nœud, commande, heure, commandes et sortie complète
Diagnostiquer
Tout diagnostic commence par des entrées reproductibles
Première connexion

Vérifiez l’identité et sécurisez le nœud en cinq étapes

RunnerVM fournit un Mac mini physique dédié, et non une machine virtuelle. Lors de la première utilisation, l’objectif n’est pas d’exécuter rapidement des commandes, mais de confirmer que vous êtes connecté à l’appareil correspondant à la commande et de remplacer l’accès initial par les paramètres de sécurité de votre équipe.

  1. 01

    Récupérer les informations de livraison dans la console

    Vérifiez l’identifiant de commande, la région du nœud, l’adresse de connexion, le port SSH, les paramètres VNC et le nom d’utilisateur initial. Ne transférez pas les identifiants complets par messagerie ; dans une équipe, ne communiquez que les champs nécessaires à l’opérateur concerné.

  2. 02

    Enregistrer d’abord l’empreinte de l’hôte

    Comparez caractère par caractère l’empreinte affichée dans la console avec celle du premier avertissement SSH. Si l’algorithme ou le condensat diffère, interrompez la connexion et envoyez un ticket. Ne contournez pas l’anomalie en supprimant l’entrée locale de known_hosts.

  3. 03

    Établir une connexion SSH en ligne de commande

    Connectez-vous avec l’hôte, le port et le nom d’utilisateur fournis dans la commande. Après la connexion, exécutez d’abord sw_vers,uname -m et hostname, puis inscrivez la version du système, l’architecture Apple Silicon et le nom de l’appareil dans le rapport de livraison.

  4. 04

    Configurer un bureau distant VNC si nécessaire

    Dans votre client VNC local, saisissez l’adresse, le port et le mot de passe indiqués dans la console. Lors de la première connexion, utilisez la résolution par défaut pour vérifier le clavier, le pointeur et le redimensionnement des fenêtres ; augmentez ensuite la taille d’affichage une fois la session stabilisée.

  5. 05

    Modifier le mot de passe et limiter les droits

    Modifiez immédiatement le mot de passe initial, vérifiez les clés publiques SSH et les droits administrateur, et ne conservez que les accès nécessaires aux tâches. Reconnectez ensuite SSH et VNC pour confirmer les nouveaux identifiants avant d’importer le projet ou les éléments de signature.

Exemples d’exécution de commandes

De la vérification de connexion à la sortie d’archive

Voici l’ordre d’une tâche de build courante avec les sorties SSH, xcodebuild et fastlane. Remplacez l’hôte, l’espace de travail, le Scheme, la configuration d’export et la lane par les valeurs réelles du projet ; ne copiez pas ces commandes telles quelles en supposant qu’elles conviennent à tous les dépôts.

  • Confirmez d’abord la cible de connexion, puis passez au répertoire du projet.
  • Utilisez un répertoire unique pour l’archive afin d’éviter les écrasements simultanés.
  • Conservez la sortie standard complète et le code de sortie, pas uniquement la dernière ligne.
runner-build-session zsh
Connexion au nœud SSH 
$ ssh -p 22 runner@10.0.0.12
Host key fingerprint: SHA256:…
$ sw_vers
ProductName: macOS
$ uname -m
arm64
Générer une archive XCODEBUILD 
$ xcodebuild archive \
-workspace RunnerApp.xcworkspace \
-scheme RunnerApp \
-archivePath build/RunnerApp.xcarchive
** ARCHIVE SUCCEEDED **
Exécuter le flux automatisé FASTLANE 
$ bundle exec fastlane ios build
[08:42:16]: Resolving signing settings
[08:43:02]: Archive completed
[08:43:11]: Export verified
[08:43:11]: fastlane finished successfully
Adaptez les exemples de commandes à l’espace de travail, au Scheme, au mode de signature et à la structure des répertoires du projet.
Préparation de l’environnement

Rendez Xcode, les éléments de signature et les répertoires vérifiables séparément

Les problèmes d’environnement ne se résument généralement pas à « Xcode s’ouvre-t-il ? », mais à la cohérence entre le choix de l’interface graphique, le chemin de la ligne de commande, les déclarations du projet et le contexte de signature. Suivez l’ordre ci-dessous pour distinguer plus vite les problèmes de chaîne d’outils de ceux du projet.

01

Vérifier la version et le chemin de Xcode

Exécutez xcodebuild -version et xcode-select -p. Si plusieurs versions sont installées sur le nœud, identifiez d’abord celle requise par le projet, puis changez le répertoire développeur afin que l’interface graphique et les tâches automatisées utilisent la même version.

02

Vérifier les Command Line Tools

Exécutez xcrun --find xcodebuild,xcrun simctl list et une résolution du projet sans signature. Si un outil est absent ou si la liste des SDK est anormale, réparez d’abord la chaîne d’outils au lieu de modifier directement les fichiers du projet.

03

Créer un trousseau de signature dédié à la tâche

Placez les certificats utilisés par les tâches automatisées dans un trousseau séparé, avec une procédure de déverrouillage explicite et un périmètre d’accès minimal. N’écrivez jamais le mot de passe dans le dépôt, les paramètres du script ou les journaux de build.

04

Importer les certificats et les profils de provisioning

Notez le nom du certificat, sa période de validité, l’identifiant d’équipe et l’UUID du profil de provisioning, puis vérifiez que le Bundle Identifier correspond à la configuration cible. Après l’import, utilisez security find-identity -v -p codesigning pour vérifier les identités disponibles.

05

Planifier les répertoires de build

Séparez le code source, le cache des dépendances, DerivedData, Archive, Export et les journaux. Utilisez un chemin d’archive unique pour chaque tâche ; le cache partagé ne doit contenir que des éléments reconstructibles, jamais des éléments de signature.

Packaging automatisé

Transformez un build réussi en six étapes reproductibles

L’objectif de l’automatisation n’est pas de déplacer un script local vers un serveur distant, mais de rendre reproductibles les entrées, l’environnement, la signature et les sorties. Chaque étape doit produire une trace claire afin d’identifier rapidement l’étape en échec.

  1. 01

    Extraire une version de code figée

    Utilisez un hash de commit ou un tag protégé, sans dépendre de la tête d’une branche susceptible d’avancer. Enregistrez la version des sous-modules, l’état de Git LFS et l’état de propreté du dépôt.

    git checkout --detach <commit>
  2. 02

    Restaurer et vérifier le cache des dépendances

    La clé de cache doit au minimum inclure le condensat des fichiers de verrouillage, la version des outils et l’architecture. En cas d’absence du cache, installez normalement ; ne faites pas d’un cache obligatoire une condition de réussite du build.

    bundle check || bundle install
  3. 03

    Charger la configuration de signature

    Déverrouillez le trousseau dédié, importez le profil correspondant et vérifiez les identités de signature disponibles. Aucune clé ni aucun mot de passe ne doit apparaître dans la sortie standard.

    security find-identity -v -p codesigning
  4. 04

    Exécuter l’Archive

    Spécifiez explicitement l’espace de travail, le Scheme, la Configuration, la Destination et le chemin d’archive. Conservez le journal complet et le code de sortie de xcodebuild.

    xcodebuild archive …
  5. 05

    Exporter les artefacts livrables

    Versionnez la configuration d’export, sans y inclure de secrets. Séparez les répertoires d’export et d’archive pour éviter d’écraser le xcarchive original lors d’une nouvelle exécution.

    xcodebuild -exportArchive …
  6. 06

    Valider et enregistrer le résultat

    Vérifiez l’existence, la taille, le condensat et les informations de signature des fichiers, ainsi que le code de sortie. Associez l’identifiant de l’artefact à la version du commit, à la version de Xcode et au chemin des journaux.

    shasum -a 256 build-output
Bureau distant

Utilisez VNC pour les opérations graphiques et confiez les tâches longues à un processus indépendant

Le bureau distant convient à la configuration graphique initiale, à la vérification de l’état de l’interface Xcode et aux tâches nécessitant une confirmation visuelle. La poursuite du build ne doit pas dépendre du maintien de la fenêtre VNC locale.

Paramètres de connexion

Utilisez strictement l’adresse, le port, le nom d’utilisateur et le mot de passe affichés dans la console. Même si le client prend en charge un fichier de configuration, n’y inscrivez pas le mot de passe en clair dans un fichier synchronisable.

Réglage de la résolution

Lors de la première connexion, utilisez la taille par défaut. Une fois l’interaction stable, augmentez progressivement la résolution ; en cas de latence, réduisez d’abord la profondeur de couleur et la taille d’affichage, puis vérifiez le chemin réseau.

Verrouillage de session

Verrouillez la session graphique avant de vous éloigner de l’appareil ; fermer le client VNC ne remplace pas le verrouillage. Lors d’un changement d’équipe, révoquez les accès devenus inutiles.

Tâches après déconnexion

Les builds persistants doivent s’exécuter dans un CI runner, launchd, tmux ou une autre session récupérable. Effectuez un test de déconnexion volontaire pour confirmer que la tâche et les journaux continuent de s’écrire.

Fiche de passation de session distante VNC / SSH
Avant de commencer Vérifier l’identité du nœud et de la session

Confirmez la région de la commande, le nom de l’appareil et l’utilisateur actuellement connecté.

Pendant l’exécution La tâche écrit dans un journal indépendant

Ne vous fiez pas uniquement à l’affichage à l’écran pour savoir si le build est toujours en cours.

Avant de partir Verrouiller la session et vérifier la tâche en arrière-plan

Après la déconnexion, vérifiez via SSH le processus, la progression du journal et l’état de sortie.

Après la passation Révoquer les accès temporaires

Supprimez les clés publiques temporaires, les fichiers à usage unique et les identifiants devenus inutiles.

Réseau et latence

Enregistrez simultanément connectivité, chemin, résolution et port

Un problème réseau doit préciser « depuis où, à quelle heure, vers quelle cible et avec quelle sortie complète ». Une capture isolée ou la phrase « la connexion est lente » ne permet pas de distinguer réseau local, chemin interrégional, DNS, stratégie de ports et état du service cible.

PING

Vérifier l’aller-retour et les pertes de paquets

Envoyez un nombre fixe de paquets et conservez les latences minimale, moyenne et maximale ainsi que le taux de perte. Une seule réponse ne représente pas la qualité de toute la connexion.

ping -c 20 target-host
TRACEROUTE

Identifier l’emplacement du changement de chemin

Exécutez la commande depuis le réseau source concerné et conservez tous les sauts. L’absence de réponse d’un nœud intermédiaire ne signifie pas une rupture ; vérifiez aussi l’accessibilité de la cible finale.

traceroute target-host
DNS

Vérifier le résultat et la durée de résolution

Notez le serveur DNS utilisé, les adresses renvoyées et la durée de la requête. Si les résultats diffèrent selon les réseaux, envoyez les sorties des deux côtés sans les réécrire manuellement.

dig target-host
PORT

Vérifier l’accessibilité du port cible

Testez séparément le port SSH ou celui réellement utilisé par le projet. Une connexion réussie prouve uniquement l’accessibilité TCP, pas la réussite de l’authentification ni du protocole applicatif.

nc -vz target-host 22
Dossier de diagnostic du ticket

Les cinq éléments obligatoires à l’envoi

NET-CHECK
Heure du problème
Indiquez la date locale, l’heure, le fuseau horaire et la durée.
Emplacement de la source
Précisez le nœud source, le réseau professionnel ou domestique et l’opérateur.
Informations sur la cible
Indiquez l’identifiant de commande, la région du nœud, l’hôte cible et le port.
Sortie complète
Joignez les résultats bruts de ping, traceroute, DNS et du test de port.
Résultat comparatif
Si possible, ajoutez le même test effectué depuis un autre réseau ou à un autre moment.

Retirez les mots de passe, clés privées, jetons et données métier avant l’envoi, mais conservez les horodatages, codes d’erreur, sauts de chemin et paramètres des commandes.

Étapes d’escalade

Réduisez d’abord le périmètre du problème, puis envoyez un ticket traçable

Les questions avant-vente, demandes générales et informations sans lien avec une commande peuvent être envoyées par e-mail. Pour un nœud, un échec de build, un problème de connexion ou une facture, connectez-vous à la console et envoyez un ticket afin de l’associer à la commande et de suivre son traitement.

  1. 01

    Rechercher et suivre le guide correspondant

    Choisissez le parcours de première connexion, de préparation d’environnement, d’automatisation ou de diagnostic réseau. Notez les étapes exécutées, les commandes, les résultats et le point de première apparition de l’anomalie.

  2. 02

    Préparer le matériel minimal de reproduction

    Fournissez l’identifiant de commande, la région du nœud, l’heure du problème, les étapes de reproduction, les résultats attendus et observés ainsi que les journaux complets après masquage des données sensibles. Pour un problème de build, indiquez aussi le commit et la version de Xcode.

  3. 03

    Envoyer un ticket depuis la console

    Choisissez la catégorie la plus proche du problème et joignez les journaux ou insérez-les dans un bloc de code. Un ticket doit traiter un seul problème ; ne mélangez pas réseau, build et facturation.

  4. 04

    Ajouter les avancées au ticket initial

    Après un nouveau test, répondez au ticket existant avec la nouvelle heure, les commandes et les sorties. Même en cas d’urgence, consultez l’état depuis la console au lieu de créer plusieurs tickets identiques.

Associé à une commande précise

Ticket dans la console

Convient aux échecs de connexion, anomalies de nœud, problèmes d’environnement de build, vérifications de facturation et demandes nécessitant un suivi. Le ticket peut être associé à la commande et conserver toute la chronologie du traitement.

  • Identifiant de commande et région du nœud
  • Heure du problème avec fuseau horaire
  • Étapes de reproduction et sortie d’erreur complète
  • Commandes de diagnostic exécutées et résultats
Se connecter à la console pour envoyer un ticket
Demande générale

Envoyer un e-mail à l’assistance

Convient au choix d’offre avant-vente, à la confirmation d’un processus, aux signalements de sécurité et aux demandes sans lien avec un nœud. Indiquez la catégorie dans l’objet et n’incluez aucun mot de passe ni aucune clé dans le message.

support@runnervm.com
Besoin d’un modèle

Commencer par générer une description structurée

La page de contact liste les informations obligatoires pour les demandes avant-vente, techniques, de facturation et de sécurité ; utilisez-la pour vérifier votre dossier avant l’envoi.

Voir les informations de contact
Questions fréquentes

Vérifiez ces limites avant de commencer le diagnostic

Les réponses suivantes servent à distinguer livraison de l’appareil, modes de connexion, tâches de build et éléments d’assistance, afin d’éviter les essais dans la mauvaise direction.

RunnerVM fournit-il une instance virtuelle ?

Non. La commande correspond à un Mac mini physique dédié, modèle Runner M4 : Mac Mini M4, 16GB RAM, 256GB SSD. La connexion à distance est uniquement un mode d’accès et ne transforme pas le service en ressource virtuelle partagée.

Le build continue-t-il après la déconnexion de VNC ?

Cela dépend du mode de lancement. Un CI runner, launchd, tmux ou un processus d’arrière-plan indépendant ne dépend généralement pas de la fenêtre VNC ; une tâche interactive liée à la session graphique peut être affectée. Avant la mise en production, déconnectez-vous volontairement une fois et vérifiez le processus, les journaux et l’état de sortie.

Que faut-il préparer avant la première connexion ?

Préparez des clients SSH et VNC fonctionnels, le mode de conservation des identifiants de l’équipe, la version de Xcode requise par le projet, la liste des éléments de signature et un processus de gestion des secrets qui n’écrit rien dans le dépôt. Après réception des informations, vérifiez d’abord l’empreinte de l’hôte et l’identité de l’appareil.

Le diagnostic modifie-t-il la période de facturation de la commande ?

Non, pas automatiquement. Runner M4 peut être commandé à la journée, à la semaine, au mois ou au trimestre ; la période et l’état de la commande sont ceux indiqués dans la console. Pour vérifier une commande précise, envoyez un ticket associé depuis la console.

Que faut-il nettoyer une fois la tâche terminée ?

Exportez d’abord les archives, artefacts et journaux anonymisés à conserver, puis nettoyez le workspace source, le trousseau de signature temporaire, les profils, les clés publiques temporaires, les jetons d’accès et les données sensibles du cache du projet. Ne conservez pas d’identifiants en clair dans l’historique shell ou les paramètres de script.

Comment choisir le bon nœud ?

Testez d’abord la latence et le chemin vers la région cible depuis le réseau professionnel ou la source CI réelle, puis tenez compte du fuseau horaire de l’équipe et du sens de transfert des artefacts. Runner M4 est disponible à la commande sur cinq nœuds : Singapour, Tokyo, Séoul, Hong Kong et côte Est des États-Unis. La disponibilité réelle est indiquée en temps réel dans la console.

Prochain build

Commencez avec un Mac dans le cloud vérifiable

Choisissez Runner M4 et la région cible, finalisez la commande, puis suivez cette page pour vérifier la connexion, préparer la chaîne d’outils et exécuter votre première tâche de build reproductible.

Louer un Mac dans le cloud Contacter l’assistance RunnerVM