De la première connexion à la première livraison

Connexion, build, livraison

Vérifiez d’abord dans le portail que votre instance est prête, puis connectez-vous à votre Mac mini physique dédié. Lancez les builds en ligne de commande, vérifiez l’environnement sur le bureau graphique et confiez les tâches répétitives à la CI.

Vous avez déjà une instance ? Consultez ses paramètres de connexion. Pour en louer une, passez commande. Les identifiants ne sont pas affichés sur les pages publiques.

Vérifiez d’abord l’état de l’instance

Choisissez une méthode de connexion

Ouvrez les détails de l’instance dans le portail et vérifiez son identifiant, son emplacement et son état. L’adresse publique, le nom d’utilisateur, le port et les identifiants initiaux sont ceux fournis pour cette instance. Ne réutilisez pas les paramètres d’une autre machine.

Connexion SSH

Idéale pour lancer des commandes de build, transférer des fichiers et consulter les journaux. Le port SSH par défaut est 22. Si l’instance indique un autre port, utilisez celui-ci.

Récupérez l’adresse de l’hôte et le nom d’utilisateur dans les détails de l’instance. Lors de la première connexion, vérifiez l’empreinte de l’hôte, puis configurez votre clé publique. Gardez votre clé privée en local et ne la joignez pas à un ticket.

Voir un exemple de premier build

Bureau graphique VNC

Pratique pour ouvrir Xcode, vérifier Simulator et régler les options de l’interface graphique. Le port VNC par défaut est 5900. Retrouvez l’adresse de connexion, le mot de passe et le port dans les détails de l’instance.

Une fois connecté, vérifiez que le bureau répond. N’utilisez pas le mot de passe VNC dans un dépôt de code. Si votre réseau le permet, privilégiez une connexion contrôlée ou un tunnel SSH.

Dépanner le bureau graphique

Terminal web du portail

Connectez-vous au portail, puis consultez le point d’accès indiqué dans les détails de l’instance. Si un terminal web est disponible, la connexion du navigateur passe par HTTPS, généralement sur le port 443. Aucun port de terminal n’est à renseigner.

L’accès utilise la session du compte connecté : il ne s’agit pas d’un lien public autonome. Si le point d’accès n’apparaît pas pour votre instance, utilisez SSH ou VNC. N’essayez pas de deviner l’adresse du terminal.

Voir les accès de l’instance
Validez un build avant de configurer le pipeline

Vérifiez séparément la connexion et le build

Commencez par vérifier que vous pouvez vous connecter, puis contrôlez le chemin d’accès et la version de Xcode. L’exemple ci-dessous illustre le format de sortie, pas les journaux en temps réel de votre instance. Le nom de session, le numéro de build et la durée sont là pour vous aider à vous repérer.

merge@tokyo-m4pro-07 Exemple de sortie de build
$ ssh -p <SSH_PORT> <USER>@<HOST>
Welcome to MergeMac
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ xcodebuild -version
$ cd <PROJECT_DIRECTORY>
$ xcodebuild -scheme App archive
** ARCHIVE SUCCEEDED **
$ fastlane pilot upload
Successfully uploaded Build 214

Remplacez les paramètres avant l’exécution

Remplacez les valeurs entre chevrons par celles indiquées dans les détails de l’instance. App est un nom de scheme d’exemple. Pour un projet workspace, ajoutez votre propre option -workspace et vérifiez que le scheme est partagé.

Une archive réussie ne signifie pas que l’envoi est terminé

Le téléversement nécessite aussi une signature valide, une configuration d’exportation et des identifiants d’envoi. Cet exemple suppose que fastlane est configuré dans le projet. Build 214 ne confirme pas votre livraison : fiez-vous à la sortie réelle de l’outil d’envoi.

Attribuez des tâches précises à votre machine

Configurer un runner auto-hébergé

MergeMac fournit des machines physiques dédiées. Vous gérez les autorisations du dépôt, la configuration des tâches CI et les identifiants. Commencez par lancer un archive dans le terminal avec le même utilisateur que celui qui exécutera les tâches, puis enregistrez le runner. Vous éviterez ainsi de confondre un problème d’environnement avec un problème de planification.

GitHub Actions

  1. Dans les paramètres des runners Actions du dépôt ou de l’organisation cible, choisissez macOS et l’architecture Apple Silicon correspondante.
  2. Sur le nœud loué, téléchargez, vérifiez et enregistrez le runner à l’aide des commandes affichées sur la page. Le token d’enregistrement est sensible : ne le mettez ni dans le dépôt ni dans une capture d’écran.
  3. Ajoutez des étiquettes, par exemple mergemac, macos et m4. Utilisez les mêmes étiquettes dans runs-on de votre workflow.
  4. Lancez une tâche qui vérifie uniquement la version de Xcode. Vérifiez qu’elle est prise en charge par le bon nœud avant d’ajouter l’installation des dépendances, l’archive et le téléversement.

Ne laissez pas des demandes de fusion externes non fiables utiliser directement un runner disposant de certificats de signature. Gérez séparément les autorisations des tâches de publication et des tâches de validation ordinaires.

GitLab Runner

  1. Créez un runner au niveau du projet ou du groupe, puis récupérez l’adresse du service et le token d’authentification requis par la procédure d’enregistrement en cours.
  2. Installez sur le nœud une version de GitLab Runner correspondant à son architecture et suivez les instructions générées pour l’enregistrer. Pour utiliser la chaîne d’outils Xcode locale, choisissez un mode d’exécution Shell adapté.
  3. Définissez des étiquettes telles que macos et xcode, puis indiquez-les explicitement dans la tâche. Réservez le runner de publication aux branches ou étiquettes protégées.
  4. Lancez d’abord une tâche de vérification de l’environnement. Contrôlez le répertoire de travail, l’utilisateur d’exécution et l’accès au trousseau avant d’activer les builds de production.

Avant de renouveler le token ou à la fin de la location, révoquez l’autorisation du runner sur la plateforme CI. Supprimer les fichiers du nœud ne révoque pas automatiquement cette autorisation.

Comprendre les termes du portail

Huit termes à connaître

Ces termes décrivent les ressources et les modes de connexion. Ils n’incluent aucune licence logicielle supplémentaire et ne combinent pas plusieurs machines en un Mac plus puissant.

Machine physique
Un Mac mini attribué individuellement dans un centre de données, avec un véritable environnement de développement macOS.
Machine dédiée
Pendant la location, le CPU, le GPU, la mémoire unifiée et le stockage local de la machine sont réservés à un seul client.
Sans machine virtuelle
Vous utilisez directement le système de la machine physique, et non une instance virtuelle hébergée sur un serveur partagé.
VNC
Protocole permettant d’afficher et de contrôler à distance le bureau graphique de macOS.
SSH
Protocole de connexion chiffrée pour ouvrir une session en ligne de commande, exécuter des commandes et transférer des fichiers.
Runner auto-hébergé
Exécuteur CI installé sur le nœud que vous louez. Votre pipeline lui attribue les tâches de build.
Mémoire unifiée
Mémoire partagée par le CPU et le GPU d’une puce Apple. L’espace réellement disponible dépend aussi des ressources utilisées par le système et les autres processus.
Connexion Thunderbolt 5
Reliez directement plusieurs appareils en Thunderbolt 5 pour réaliser des essais multi-machines. La répartition des tâches dépend toujours de la prise en charge par l’application.
Conservez les éléments de diagnostic avant de modifier l’environnement

Partez du symptôme pour trouver la cause

Notez l’heure et le fuseau horaire, l’identifiant de l’instance, le message d’erreur complet et les dernières modifications. Ne changez qu’un élément à la fois, puis répétez le même test. La réinstallation n’est pas la première solution à essayer.

  1. 01

    Écran noir ou VNC sans réponse

    Vérifiez d’abord dans le portail que l’instance est prête, puis essayez de vous connecter en SSH. Si SSH fonctionne mais que le bureau graphique pose problème, vérifiez qu’une session graphique n’est pas en cours d’ouverture, de fermeture ou de changement. Fermez le client et reconnectez-vous.

    Si l’écran reste noir, conservez la version du client et une capture d’écran, puis ouvrez un ticket. Ne désactivez pas le pare-feu pour faire un essai et ne forcez pas plusieurs redémarrages : vous pourriez interrompre les builds en cours.

  2. 02

    Version de Xcode différente

    Exécutez xcode-select -p et xcodebuild -version. Vérifiez les résultats dans la session interactive et dans le runner. Installer plusieurs versions ne change pas automatiquement celle utilisée en ligne de commande.

    Pour une tâche ponctuelle, utilisez DEVELOPER_DIR pour indiquer le répertoire Developer de la version de Xcode souhaitée. Vous éviterez ainsi de changer la version par défaut et d’affecter d’autres tâches. Si le répertoire est introuvable, vérifiez le chemin d’installation au lieu de reprendre un nom d’exemple.

  3. 03

    Simulator manque d’espace disque

    Consultez l’espace disponible avec df -h, puis vérifiez DerivedData, les archives, les données des appareils et les runtimes des simulateurs. Exportez d’abord les builds à conserver et arrêtez les tâches qui utilisent des simulateurs.

    xcrun simctl delete unavailable supprime les entrées des appareils simulateurs indisponibles, mais ne supprime pas tous les runtimes. Vérifiez les éléments concernés avant le nettoyage et n’appliquez pas de suppression récursive aux répertoires du projet ou aux trousseaux.

  4. 04

    Certificat de signature invalide

    Déterminez s’il s’agit d’un certificat expiré, d’un profil de provisionnement invalide, d’une clé privée manquante ou d’un trousseau verrouillé. Vérifiez la date de validité du certificat ainsi que la correspondance de l’équipe et de l’identifiant de bundle, puis assurez-vous que l’utilisateur CI peut lire la clé privée concernée.

    Après le renouvellement du certificat, mettez à jour le profil de provisionnement et les variables protégées, puis relancez la vérification avec le même scheme. Dans un ticket, joignez uniquement le code d’erreur et des journaux expurgés. N’envoyez ni clé privée, ni mot de passe d’exportation de certificat, ni dossier de signature complet.

Sauvegardez vos données avant toute réinstallation

La réinstallation modifie l’environnement et n’en conserve pas les fichiers

La réinstallation du système et l’effacement des données à la fin de la location sont deux opérations distinctes. Ne stockez pas votre code source, vos éléments de signature ou vos builds uniquement sur le nœud loué.

Réinstaller pendant la location

Dans les détails de l’instance du portail, avant de lancer la réinstallation, arrêtez la planification CI, exportez vos projets, vos builds et les configurations nécessaires, puis vérifiez que la sauvegarde s’ouvre depuis un autre emplacement.

L’initialisation prend généralement quelques minutes. La durée réelle et l’état d’avancement sont ceux indiqués par le portail. Ne relancez pas l’opération pendant son exécution. Une fois terminée, récupérez les identifiants de connexion, vérifiez l’empreinte de l’hôte et reconstituez votre environnement de développement.

Après la réinstallation, vérifiez de nouveau SSH, Xcode, les dépendances et le runner. Ne partez pas du principe que l’ancienne configuration est toujours présente.

Effacement du disque à l’échéance

À la fin de la location, le nœud passe par une procédure d’effacement des données et de réinitialisation du système avant d’être attribué à un autre client. Exportez les données à conserver avant l’échéance : ne comptez pas sur un accès encore disponible après la fin de la location pour faire office de sauvegarde.

Pensez également à révoquer les clés de déploiement des dépôts, les tokens des runners CI et les identifiants d’envoi. L’effacement du disque supprime les données du nœud, mais ne révoque pas les accès accordés dans des systèmes externes.

Pour toute question sur le traitement des données ou les limites de sécurité, consultez d’abord la documentation de sécurité, puis contactez-nous par ticket depuis le portail pour vérifier la situation de l’instance concernée.

Facilitez le diagnostic dès notre prochaine réponse

Contacter l’assistance

Pour un problème concernant une instance louée, privilégiez un ticket depuis le portail afin de le relier à la commande et au nœud concernés. Si vous ne pouvez pas vous connecter, pour une question avant-vente ou pour signaler un problème de sécurité, écrivez à l’adresse d’assistance. Évitez de signaler plusieurs fois le même problème par différents canaux.

Ticket dans le portail

Connectez-vous, ouvrez la section des tickets et indiquez l’identifiant de l’instance, l’étendue de l’impact et les étapes pour reproduire le problème. Pour faire remonter un problème déjà signalé, répondez au ticket existant afin de conserver un seul historique de diagnostic.

Format conseillé : heure et fuseau horaire → résultat attendu → erreur constatée → actions déjà tentées. Joignez un extrait aussi court que possible des journaux, après en avoir masqué les données sensibles. N’envoyez pas l’intégralité du code source.

Se connecter et ouvrir un ticket

E-mail d’assistance

Si vous ne pouvez pas accéder à votre compte, précisez la catégorie du problème dans l’objet et indiquez l’adresse e-mail de votre compte ainsi qu’un numéro de commande permettant de vérifier votre demande. N’envoyez ni mot de passe ni numéro de carte bancaire.

L’assistance coordonne ses réponses sur les fuseaux horaires de l’Asie-Pacifique et de la côte est des États-Unis. Le délai de première réponse dépend du niveau de priorité et de la file en cours. Consultez les réponses au ticket ou à l’e-mail pour suivre l’avancement ; aucun délai moyen non publié n’est garanti ici.

support@mergemac.com

Configurez l’environnement, puis confiez-lui vos builds

Vous avez déjà une machine ? Vérifiez son état dans le portail. Pour ajouter un nœud de build, choisissez une configuration à louer. Chaque Mac mini est physique, dédié et non virtualisé.