Support technique pratique

Du Mac dans le cloud à la livraison des artefacts de build, résolvez les problèmes étape par étape

Ce n’est pas une documentation théorique. Chaque guide détaille les prérequis, les étapes, les résultats à vérifier et les journaux à conserver en cas d’échec. Pour SSH, le bureau distant VNC, Xcode, fastlane, les Runners auto-hébergés et la facturation.

Ouvrir un ticket depuis la console Voir l’index des guides
4 guides pratiques 5 nœuds de service 365 jours de disponibilité
build-diagnostics Vérification réussie
Modes de connexion SSH / VNC
Outils de build Xcode / fastlane
Architecture d’exécution Apple Silicon
$ xcodebuild -version Xcode 16.x $ uname -m arm64 $ df -h / volume check: ready
Validez d’abord l’environnement, puis lancez le pipeline complet Isolez l’échec : connexion, dépendances, signature ou concurrence.
Recherche dans le centre de support

Filtrez par tâche, sans tout lire depuis le début

Sélectionnez la tâche en cours ou saisissez des mots-clés comme SSH, archive, signature, Runner, nœud ou facturation. Le filtre ne modifie que les cartes de l’index ; les étapes complètes restent disponibles plus bas sur cette page.

Catégories de tâches

Afficher 9 guides

Connexion de l’appareil

Première connexion SSH et VNC

Préparez votre clé publique, vérifiez l’empreinte de l’hôte, contrôlez l’environnement arm64, puis fermez proprement la session graphique.

Environ 10 minutes Configuration de l’environnement

Choisir Xcode et installer les dépendances

Verrouillez les versions de la toolchain, validez les chemins en ligne de commande, puis restaurez les dépendances Ruby, Pods ou Swift Package depuis les fichiers de verrouillage.

Environ 15 minutes Exécution du build

Archiver et exporter les artefacts

Lancez l’archive en indiquant explicitement le workspace, le scheme et la destination, puis conservez le xcresult et les journaux d’export.

Environ 20 minutes Exécution du build

Automatisation et nettoyage avec fastlane

Injectez les variables sensibles uniquement pendant la tâche, exécutez le lane défini, puis supprimez les fichiers temporaires et l’environnement du processus après avoir conservé les artefacts.

Environ 20 minutes Exécution du build

Intégrer un Runner Mac auto-hébergé

Enregistrez un Runner dédié, limitez les dépôts autorisés, définissez les labels de capacités et nettoyez le répertoire de travail après chaque tâche.

Environ 25 minutes Configuration de l’environnement

Cinq vérifications pour diagnostiquer un build en échec

Vérifiez successivement le réseau, le disque, les éléments de signature, le cache des dépendances et la concurrence ; ne modifiez pas plusieurs variables à la fois.

Environ 15 minutes Connexion de l’appareil

Choisir un nœud et demander une migration

Choisissez l’un des cinq nœuds selon l’emplacement des développeurs, du dépôt de code et des services du pipeline, puis demandez la migration via un ticket.

Environ 5 minutes Gestion de la facturation

Vérifier la commande et les options supplémentaires

Indiquez l’identifiant de commande, la durée de location, le nœud et les options de stockage ou de mise en parallèle Thunderbolt 5 pour retrouver facilement la facture.

4 informations à préparer Gestion de la facturation

Contacter le support humain

Depuis la console ou par e-mail au support, fournissez l’identifiant de l’appareil, le nœud, la période concernée et des journaux expurgés.

Deux moyens de contact
Guide de connexion

Établissez une connexion fiable avant de configurer l’environnement

Fiez-vous aux informations affichées dans la console. Ne collez jamais de clé privée, d’identifiant à usage unique ou de commande de connexion complète dans un dépôt public, un journal de build ou un groupe d’équipe.

Connexion SSH en ligne de commande

  1. 1
    Préparer la clé publique locale

    Privilégiez une clé distincte protégée par une phrase secrète. Téléversez uniquement la clé publique ; n’envoyez jamais le contenu de la clé privée par ticket ou par e-mail.

  2. 2
    Lire les informations de connexion

    Dans la console, vérifiez l’identifiant de l’appareil, le nœud, l’adresse de l’hôte, le port et le nom d’utilisateur afin de ne pas réutiliser une ancienne location.

  3. 3
    Vérifier l’empreinte de l’hôte

    Comparez l’empreinte fournie par la console avant la première connexion. Si elle diffère, interrompez la connexion et ouvrez un ticket ; ne remplacez pas directement l’enregistrement local.

  4. 4
    Effectuer les vérifications de base

    Exécutez uname -m,xcodebuild -version et df -h / ; consignez l’architecture, la toolchain et l’espace disque disponible.

Connexion au bureau distant VNC

  1. 1
    Vérifier d’abord que SSH fonctionne

    Si la connexion graphique échoue, SSH est le moyen principal de vérifier les processus, le disque et le réseau. Commencez par valider l’empreinte de l’hôte.

  2. 2
    Récupérer les informations de session dans la console

    Utilisez l’entrée VNC et les identifiants temporaires associés à l’appareil actuel. Ne les enregistrez ni dans la synchronisation du navigateur, ni dans un document partagé, ni dans les variables du pipeline.

  3. 3
    Vérifier l’environnement graphique

    Après la connexion, vérifiez la résolution, la disposition du clavier, l’état de lancement de Xcode et l’espace disponible avant toute signature ou archivage.

  4. 4
    Terminer et nettoyer la session

    Quittez les outils de développement en cours, supprimez les téléchargements temporaires et les identifiants en clair, puis fermez la session de bureau distant.

Règles de gestion des identifiants :Chaque membre de l’équipe doit utiliser son propre mode d’accès contrôlé. Lorsqu’une personne quitte le projet, révoquez sa clé publique et ses jetons de pipeline ; ne vous contentez pas de modifier la configuration SSH locale.
Guide des builds Xcode

Documentez les versions, les dépendances et les paramètres d’export pour rendre les builds reproductibles

Ne vous fiez pas au scheme sélectionné lors de la dernière utilisation de l’interface graphique. Les tâches automatisées doivent préciser le chemin Xcode, le workspace, le scheme, la configuration, la destination et la configuration d’export.

01

Choisir et valider la version de Xcode

Lisez d’abord les exigences du projet, puis utilisez xcode-select pour cibler la version souhaitée. Exécutez ensuite xcodebuild -version et xcrun swift --version séparément, puis inscrivez leur sortie au début du journal de build.

02

Installer les dépendances depuis le fichier de verrouillage

Pour un projet Ruby, exécutez d’abord bundle install ; pour Pods, restaurez selon le fichier de verrouillage ; pour Swift Package, résolvez d’abord les dépendances. Le cache accélère l’installation, mais ne remplace pas les contraintes de version du fichier de verrouillage.

03

Exécuter la tâche d’archivage

Dirigez DerivedData et archivePath vers des répertoires distincts pour la tâche en cours. Les tâches concurrentes ne doivent pas partager le même chemin de sortie, afin d’éviter l’écrasement mutuel des index, caches ou archives.

04

Exporter et valider les artefacts

Exportez avec une configuration versionnée. Vérifiez le code de sortie, les fichiers produits, le résultat de la signature et le dSYM, puis copiez les artefacts dans un répertoire de livraison contrôlé.

05

Conserver des journaux exploitables

Conservez au minimum la sortie de build en texte brut, les journaux d’export et le xcresult. Le nom de fichier doit contenir l’identifiant de la tâche du pipeline, sans jeton d’accès, clé privée ni élément de signature complet.

archive.sh 
xcode-select -p
xcodebuild -version
xcrun swift --version

bundle install
bundle exec pod install

xcodebuild archive \
  -workspace App.xcworkspace \
  -scheme App \
  -configuration Release \
  -destination "generic/platform=iOS" \
  -archivePath output/App.xcarchive \
  -resultBundlePath output/App.xcresult

xcodebuild -exportArchive \
  -archivePath output/App.xcarchive \
  -exportPath output/export \
  -exportOptionsPlist ExportOptions.plist
Entrées Dépôt, fichiers de verrouillage, variables d’environnement contrôlées Lieu d’exécution Mac dans le cloud dédié Sorties Archive, fichiers exportés, xcresult, journaux expurgés
Guide d’automatisation fastlane

Les variables sensibles n’existent que pendant la tâche

fastlane doit orchestrer les étapes de build, pas conserver durablement les secrets. Les éléments de signature, jetons de dépôt et identifiants d’envoi doivent être injectés via des variables contrôlées, puis supprimés à la fin de la tâche.

INPUT

Injecter les clés et la configuration de signature

Injectez uniquement les variables nécessaires au démarrage de la tâche. Placez les fichiers temporaires dans un répertoire dédié, limitez leurs permissions et évitez d’afficher leurs valeurs dans la sortie des commandes.

  • Le nom de la variable peut être journalisé, jamais sa valeur
  • La configuration de signature doit correspondre clairement à la branche du projet
  • Le répertoire temporaire ne doit pas être réutilisé par une tâche ultérieure
RUN

Exécuter le lane défini

Utilisez bundle exec fastlane pour figer les versions de Ruby et des gems. Le lane doit préciser le scheme, le mode d’export, le répertoire de sortie et les conditions d’échec.

  • Affichez les versions des outils avant le build, jamais les identifiants
  • En cas d’échec, conservez le journal de la tâche et le xcresult
  • Avant de réessayer, déterminez s’il s’agit d’un problème d’environnement ou de code
CLEAN

Conserver les artefacts et nettoyer

Copiez d’abord l’archive, les fichiers exportés et les journaux dans un emplacement contrôlé, puis supprimez les fichiers de signature temporaires, fichiers d’environnement, caches téléchargés et répertoire de travail.

  • Vérifiez que les artefacts existent et que leur taille est cohérente
  • Effacez les commandes sensibles de l’historique du shell
  • Vérifiez qu’aucun processus de build ne reste en arrière-plan
bundle exec fastlane ios archive Versions de dépendances figées Répertoire de sortie dédié Code de sortie non nul en cas d’échec
Guide d’intégration CI/CD

Intégrez le Mac dans le cloud au pipeline comme nœud d’exécution contrôlé

Le Runner doit être associé à un périmètre précis de dépôt ou de projet. N’accordez pas automatiquement à une branche non fiable l’accès aux éléments de signature de production et ne faites pas partager un répertoire de travail à des tâches de niveaux de sécurité différents.

GitHub Actions

Processus d’intégration d’un Runner auto-hébergé

  1. Définir le périmètre

    Selon le modèle d’autorisations de l’équipe, choisissez un Runner au niveau du dépôt ou de l’organisation et limitez les projets qui peuvent l’utiliser.

  2. Créer un utilisateur système dédié

    Le processus du Runner ne doit pas utiliser un compte d’administration courant. Accordez uniquement les permissions nécessaires au répertoire de travail et aux outils de build.

  3. Définir les labels de capacités

    Les labels doivent indiquer l’architecture, la version majeure de Xcode et le type de tâche afin que le workflow sélectionne le bon nœud.

  4. Configurer la stratégie séquentielle ou parallèle

    Un répertoire de travail ne doit traiter qu’une tâche à la fois. Pour exécuter des tâches en parallèle, utilisez des répertoires ou des appareils distincts.

  5. Nettoyer après chaque tâche

    Supprimez les fichiers de variables temporaires, éléments de signature et artefacts non envoyés ; vérifiez les processus résiduels avant d’accepter la tâche suivante.

Systèmes de pipeline courants

Intégration via un exécuteur Agent ou SSH

  1. Créer un point d’entrée unidirectionnel

    Le pipeline planifie les tâches sur le Mac dans le cloud ; évitez d’inscrire les identifiants d’administration de l’appareil dans la configuration du dépôt.

  2. Limiter les commandes et les répertoires

    L’utilisateur de build n’accède qu’aux dépôts, caches et chemins de sortie autorisés ; les opérations d’administration passent par un chemin doté de permissions distinctes.

  3. Prévalider la toolchain

    Avant le build officiel, vérifiez l’architecture, Xcode, Ruby, le gestionnaire de dépendances et l’espace disque. Si la prévalidation échoue, arrêtez la tâche.

  4. Uniformiser les codes de sortie

    Tout échec de l’installation des dépendances, des tests, de l’archivage ou de l’export doit renvoyer un état non nul pour éviter que le pipeline ne signale à tort une réussite.

  5. Nettoyer après l’envoi

    Vérifiez que les artefacts et journaux ont été envoyés, puis nettoyez le répertoire de la tâche. Conservez l’identifiant de tâche pour le relier au ticket.

Conseil pour la concurrence :La configuration de base — M4, 16 Go, 256 Go — convient aux builds légers et à la signature d’un projet. La configuration Pro — M4 Pro, 64 Go, 2 To — convient mieux aux builds fortement parallélisés et aux caches de dépendances volumineux. Choisissez selon le pic de mémoire d’un build, le nombre de tâches parallèles et la taille du cache.
Checklist de dépannage

Éliminez une seule variable à la fois

Notez d’abord l’identifiant de la tâche en échec et la période concernée, puis vérifiez dans l’ordre le réseau, le disque, la signature, le cache et la concurrence. Conservez le résultat de chaque vérification et évitez de réinstaller inutilement l’environnement.

Comment diagnostiquer les délais d’attente réseau et de connexion

Vérifiez d’abord que le réseau local atteint le port de l’appareil, puis contrôlez le DNS, le proxy, l’empreinte SSH de l’hôte et l’heure système. Notez séparément l’heure d’établissement, l’heure de déconnexion et le message d’erreur exact. Si SSH fonctionne mais pas VNC, vérifiez le processus de session graphique au lieu de réinitialiser tout l’environnement.

ssh -v user@host
Espace disque insuffisant ou échec d’écriture de l’archive

Utilisez df -h / pour consulter l’espace disponible, puis vérifiez DerivedData, le cache des dépendances, les anciennes archives et les données des simulateurs. Repérez d’abord les gros répertoires, puis supprimez uniquement les caches clairement recréables. Ne nettoyez pas pendant un build les répertoires qu’il utilise.

du -sh ~/Library/Developer/*
Certificat de signature ou profil de configuration incompatible

Vérifiez l’identifiant du projet, la configuration de build, le mode d’export, la validité du certificat et la correspondance avec le profil. Confirmez que le pipeline injecte les éléments requis par la tâche actuelle et contrôlez l’heure système. Dans les journaux, conservez le type d’erreur et le processus de correspondance, mais masquez le certificat, la clé privée et les jetons.

security find-identity -v -p codesigning
Dérive de version ou erreur de compilation due au cache des dépendances

Comparez d’abord le fichier de verrouillage avec les versions réellement utilisées dans les journaux. Lancez un build sans cache partagé dans un nouveau répertoire ; si le problème disparaît, restaurez progressivement les caches Swift Package, Pods, Ruby et DerivedData pour identifier la source de la contamination.

swift package resolve
Conflit de ressources dû à la concurrence des builds

Vérifiez les processus xcodebuild, de test et de dépendances actifs, ainsi que le répertoire de sortie de chaque tâche. Réduisez la concurrence et retestez en observant le pic de mémoire, les écritures disque et la durée. Les tâches ne doivent pas partager archivePath, resultBundlePath ni le répertoire temporaire de signature.

ps -axo pid,%cpu,%mem,command
Nœuds et disponibilité

Les cinq nœuds proposent deux gammes de Mac physiques dédiés

Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et côte Est des États-Unis sont disponibles 365 jours par an. Les combinaisons du catalogue sont généralement disponibles à la location ; la disponibilité réelle est celle renvoyée en temps réel par la console.

Catalogue et conseils de choix des deux modèles MiniRents sur cinq nœuds
Nœud Emplacement de l’équipe à privilégier MiniRents M4 MiniRents M4 Pro Conseil de choix
SingapourSG Équipes d’Asie du Sud-Est et dépôts proches Disponible Disponible Comparez en priorité la stabilité de la connexion entre les développeurs et le nœud, puis entre le dépôt et le nœud.
Japon (Tokyo)JP Équipes du Japon et d’Asie de l’Est Disponible Disponible Adapté aux workflows dont le dépôt et les collaborateurs se trouvent principalement en Asie de l’Est.
Corée du Sud (Séoul)KR Équipes coréennes et d’Asie de l’Est proche Disponible Disponible Avant de choisir, testez la stabilité SSH depuis le réseau professionnel réel.
Hong KongHK Équipes collaborant entre la Chine méridionale et l’Asie du Sud-Est Disponible Disponible À envisager pour les équipes réparties sur plusieurs sites asiatiques.
Côte Est des États-UnisUS-E Équipes de l’est de l’Amérique du Nord et de l’Europe occidentale Disponible Disponible Adapté aux workflows dont le dépôt, le service d’artefacts ou la majorité des membres se trouvent près de la côte Est nord-américaine.
01

Privilégier d’abord la connexion interactive

Si vous utilisez souvent VNC, privilégiez la stabilité entre le développeur et le nœud ; pour une exécution entièrement automatisée par le pipeline, l’emplacement du dépôt et du service d’artefacts est plus important.

02

Examiner ensuite le flux de données

Les téléchargements de dépendances, les clones du dépôt et l’envoi des artefacts utilisent tous la liaison. Placez les principales sources de données et le nœud d’exécution sur le chemin le plus stable.

03

Demander la migration par ticket

Indiquez l’identifiant de l’appareil actuel, le nœud actuel, le nœud cible, la période souhaitée et le motif de la migration. Le résultat et les étapes suivantes sont ceux consignés dans le ticket de la console.

Contacter le support humain

Si le guide ne suffit pas, envoyez un compte rendu reproductible du problème

Pour les problèmes techniques, utilisez en priorité un ticket depuis la console afin de l’associer à l’appareil et à la commande. Si vous ne pouvez pas vous connecter à la console, ou pour une consultation avant-vente, de facturation, de sécurité ou de déploiement d’équipe, envoyez un e-mail.

Ticket depuis la console

Pour les interruptions de connexion, l’état de l’appareil, l’environnement de build, la migration de nœud, les commandes et la facturation. Le ticket doit être associé à l’appareil ou à la commande concernés et contenir des informations reproductibles.

  • Identifiant de l’appareil et nœud actuel
  • Période de survenue du problème
  • Étapes exécutées et résultat attendu
  • Message d’erreur exact et journaux expurgés
  • Vérifications déjà effectuées
Ouvrir un ticket depuis la console

E-mail du support

Pour les problèmes de connexion à la console, l’évaluation d’une configuration avant-vente, le déploiement d’équipe, les rapports de sécurité et les demandes générales. Précisez le type de problème dans l’objet et n’incluez ni mot de passe, ni clé privée, ni jeton complet dans le message.

  • Nom et e-mail professionnel
  • Type de demande et workflow visé
  • Nœud souhaité et concurrence de build
  • Étapes de reproduction et impact du rapport de sécurité
  • Identifiant de commande et options supplémentaires concernés par la facturation
support@minirents.com
Informations de facturation

Indiquez ces quatre éléments pour toute question de facturation

Indiquez l’identifiant de commande, la durée de location, le nœud, ainsi que l’extension de stockage ou l’option de mise en parallèle Thunderbolt 5. Seuls USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) sont acceptés ; tous les frais sont facturés en dollars américains (USD), et les passerelles réellement disponibles sont celles renvoyées par l’API backend.

Prêt à lancer le build

Choisissez un Mac dans le cloud dédié et faites fonctionner votre premier pipeline

Deux modèles, quatre durées de location et cinq nœuds sont disponibles. Il s’agit de Mac physiques dédiés, non de machines virtuelles, à partir de $21.5/jour.

Louer un Mac dans le cloud maintenant Voir les offres et les tarifs