Louez un Mac mini dédié à la journée plutôt qu’une machine virtuelle partagée. Choisissez votre modèle, récupérez vos identifiants de connexion et suivez les étapes ci-dessous pour réussir votre premier build.
Livraison environ 15 minutes après le paiement. Le temps nécessaire à la première connexion et aux vérifications dépend de vos clés, de votre projet et de la configuration de signature.
Location à partir d’un jour ; deux modèles M4, avec une durée au choix : jour, semaine, mois ou trimestre. La disponibilité réelle est celle affichée en temps réel dans la console.
Lors de la commande, sélectionnez le modèle, la région, la durée et le moyen de paiement. Pour une seule livraison, commencez par un jour ; pour exécuter la CI en continu, comparez les durées à la semaine, au mois ou au trimestre. Le montant correspondant à la période choisie est réglé en une fois, en dollars américains.
Idéal pour compiler une app avec Xcode, créer des builds avec fastlane et configurer SSH, VNC et votre chaîne d’outils. Si vous comptez aussi lancer plusieurs simulateurs et conteneurs, vérifiez d’abord la consommation mémoire réelle de votre projet.
Idéal pour exécuter simultanément Xcode, des simulateurs et des conteneurs, ou pour disposer de plus d’espace pour les modèles MLX et le cache de build. Si vos fichiers de modèles sont volumineux, vérifiez les options SSD supplémentaires lors de la commande.
Choisissez parmi Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong, la côte est des États-Unis et la côte ouest des États-Unis. Privilégiez une région proche de votre équipe et de vos services de code, à laquelle vous pouvez vous connecter de façon fiable. Les deux modèles sont disponibles dans ces six régions.
Paiement accepté : USDT-TRC20 ou Visa, Mastercard et Amex via Stripe. Les moyens de paiement effectivement disponibles sont ceux indiqués dans la console.
Consultez les informations de livraison dans la console. Ne collez pas vos identifiants, votre clé privée ou vos certificats de signature dans le corps d’un ticket. Pour demander de l’aide, indiquez le numéro de commande et un extrait d’erreur expurgé de toute donnée sensible.
| Information | Utilité | Vérification |
|---|---|---|
| Adresse de l’hôte | Indique la destination des connexions SSH et VNC. | Copiez l’adresse affichée dans la console et vérifiez qu’elle ne contient pas d’espace superflu. |
| Nom d’utilisateur | Associé à l’adresse de l’hôte, il identifie votre session SSH. | Utilisez le compte associé à votre commande ; ne devinez pas le nom d’utilisateur par défaut du système. |
| Clé publique SSH | Autorise la connexion de vos appareils par clé. | Téléversez le contenu du fichier de clé publique ; conservez la clé privée sur votre propre appareil. |
| Accès VNC | Ouvre l’interface graphique de macOS. | Suivez les instructions et utilisez les identifiants indiqués sur la page de livraison. Le port VNC n’est pas un port SSH. |
Générez une paire de clés sur votre ordinateur, puis téléversez la clé publique dans la console. Connectez-vous ensuite avec la clé privée conservée sur votre appareil. Ne générez pas sur l’hôte distant l’unique clé privée servant à vous y connecter.
Vérifiez d’abord l’adresse, le nom d’utilisateur et la clé publique, puis assurez-vous que votre réseau local peut joindre la machine cible. En cas de délai d’attente de la connexion TCP, vérifiez d’abord le réseau ; si la clé publique est refusée, contrôlez l’identité et les autorisations.
Dans le terminal local, définissez les variables de connexion à partir des informations de livraison. Vérifiez d’abord macOS et l’architecture du processeur, puis recherchez les schemes disponibles depuis le répertoire du projet. Ne lancez le build ou l’archivage qu’après avoir vérifié le scheme du projet et sa configuration de signature.
ssh -i ~/.ssh/id_ed25519 "$VM_USER@$VM_HOST"Une fois la connexion établie, l’invite de commande passe sur le Mac distant. Lors de la première connexion, vérifiez l’empreinte de l’hôte avec les informations de livraison.
sw_vers -productName
uname -m
sysctl -n machdep.cpu.brand_stringLes résultats attendus sont respectivement macOS, arm64 et Apple M4. La version de macOS dépend de la machine livrée.
xcodebuild -list
xcodebuild -scheme "$SCHEME" -destination 'generic/platform=iOS' build CODE_SIGNING_ALLOWED=NOUne compilation sans signature permet de vérifier d’abord que le projet peut être compilé. En cas de succès, vérifiez le code de sortie et BUILD SUCCEEDED ; en cas d’échec, commencez par examiner la première erreur de build.
fastlane gym --scheme "$SCHEME"L’archivage et l’export nécessitent les certificats, profils de provisionnement et la configuration fastlane requis par le projet. Une fois la commande terminée, vérifiez le résultat de l’export, pas seulement la dernière ligne du journal.
Ici, VM_USER et VM_HOST et SCHEME sont des variables shell : attribuez-leur les valeurs des informations de livraison et du scheme réel du projet. Si le projet dépend d’une version précise de Xcode, exécutez xcodebuild -version pour la vérifier avant de changer de version.
SSH convient au transfert de fichiers, aux builds et à la consultation des journaux. Pour utiliser l’interface Xcode, un simulateur ou les réglages système, connectez-vous en VNC avec les informations de livraison. Les deux méthodes donnent accès au même Mac mini dédié.
Dans votre client VNC, saisissez l’adresse et les informations d’accès indiquées sur la page de livraison. Ne réutilisez pas dans le client VNC le nom d’utilisateur, la clé ou le port SSH.
Commencez avec une résolution d’affichage basse dans le client. Une fois l’image et les commandes stables, augmentez-la. Pour une utilisation à distance, privilégiez la réactivité plutôt que la qualité d’image maximale dès le départ.
Les builds doivent rester reproductibles par SSH. Ainsi, si la session VNC est interrompue, vous pouvez gérer les builds, les journaux et le dépannage CI sans dépendre de l’affichage du bureau.
En cas d’écran noir, vérifiez d’abord que vous êtes connecté à la bonne commande et à la bonne région, puis contrôlez l’état de la session. Ne modifiez pas le projet et ne supprimez pas le cache de build pour résoudre un problème d’affichage à distance.
Pour configurer un runner GitHub Actions self-hosted, générez d’abord la commande d’enregistrement et un jeton temporaire dans les paramètres du runner du dépôt, puis exécutez sur ce Mac la commande fournie à ce moment-là par la plateforme. Ne mettez pas le jeton dans le dépôt, une capture d’écran ou les journaux de build.
Enregistrez le runner auprès du dépôt à compiler ou d’une organisation contrôlée, puis attribuez-lui des labels permettant d’identifier cet hôte macOS. Vérifiez que l’interface indique que le runner est en ligne avant d’envoyer un workflow.
Le workflow doit d’abord récupérer le code, puis exécuter la même commande Xcode que lors de la vérification manuelle. Après un premier succès, ajoutez progressivement le cache des dépendances, les tests, la signature et la distribution afin d’éviter de cumuler plusieurs sources d’erreur.
Le runner peut accéder à l’environnement de build de cette machine. Définissez des autorisations pour les branches et les dépôts autorisés à le déclencher, protégez les éléments de signature et supprimez l’enregistrement du runner s’il n’est plus utilisé avant la fin de la location.
Vérifiez d’abord que le bon runner est sélectionné, que le code peut être récupéré et quexcodebuild -version renvoie la même version que lors de la vérification manuelle. Lancez ensuite le scheme validé. Le scheme, la plateforme cible et les options de signature du workflow doivent correspondre au projet : ne considérez pas l’exemple de commande comme une configuration d’export universelle.
La location commence à la livraison. Effectuez vos sauvegardes, supprimez les runners et décidez d’un éventuel renouvellement avant l’échéance. Ne laissez pas votre unique copie du code source, de vos certificats ou de vos artefacts de build sur la machine distante.
Vérifiez l’état des commits et récupérez les archives, journaux, fichiers de modèles et configurations. Testez l’ouverture des fichiers sur votre propre espace de stockage. Conservez les éléments de signature conformément aux procédures de sécurité de votre équipe.
Si le build n’est pas terminé, consultez les options de renouvellement dans la console. Si la mémoire ou le stockage limite les tâches parallèles, comparez les caractéristiques de Commit 16 et Commit 24, puis choisissez selon vos besoins réels.
Vérifiez qu’aucune tâche ne reste dans la file CI et que le runner n’est plus associé au dépôt. Le traitement des données après l’échéance est régi par les conditions du service et les règles affichées dans la console. Effectuez vos sauvegardes pendant la période de location.
Pour vérifier les méthodes de connexion, les commandes de build ou les règles de facturation, consultez d’abord la documentation. Pour configurer un environnement de développement Mac à distance, recherchez « configurer un environnement de développement Mac à distance » sur le blog. Les articles disponibles sont ceux publiés sur le blog.
Commencez par un jour, choisissez une région et un modèle, puis suivez cette checklist pour votre premier build après la livraison.