Identifiants SSH et VNC fournis à la livraison. Lancez vos builds en ligne de commande et vérifiez la signature à distance. Ce Mac physique dédié, non virtualisé, est réservé à votre usage.
Vous avez déjà un nœud ? Notez son adresse, son port SSH, son nom d’utilisateur et son mode d’accès au bureau avant de suivre les étapes ci-dessous.
Générez une clé sur votre ordinateur, autorisez sa clé publique sur le Mac cloud, puis attribuez un alias fixe au nœud. Réutilisez cette connexion avec rsync, Fastlane et votre runner.
Voici 192.0.2.10 une adresse réservée aux exemples de documentation,macbuild un nom d’utilisateur fictif, et22 un port SSH d’exemple. Remplacez-les tous par les valeurs fournies dans la console. Ne collez jamais votre clé privée, votre mot de passe ni vos identifiants de connexion complets dans un ticket.
Exécutez ces commandes en local. Un nom de fichier distinct facilite la révocation de l’autorisation sans écraser votre clé par défaut. Définissez une phrase secrète lorsque vous y êtes invité. Dans un environnement automatisé, gérez l’accès avec un système de gestion des secrets contrôlé : ne stockez pas la clé privée dans votre dépôt.
ssh-keygen -t ed25519 -f ~/.ssh/xcr_build -C "xcr-build"
ssh-add ~/.ssh/xcr_build
ls -l ~/.ssh/xcr_build.pubLes fichiers portant le suffixe .pub contiennent la clé publique, que vous pouvez installer sur le nœud. Le fichier sans suffixe contient la clé privée : conservez-la uniquement en local ou dans un stockage de secrets CI contrôlé.
Si ssh-copy-id est installé en local, utilisez le nom d’utilisateur et le port fournis pour installer la clé publique. À la première connexion, une empreinte de l’hôte s’affiche : comparez-la aux informations reçues. Si vous ne disposez pas d’une empreinte fiable, demandez confirmation via un ticket dans la console ; ne passez pas la vérification.
ssh-copy-id -i ~/.ssh/xcr_build.pub -p 22 macbuild@192.0.2.10
ssh -i ~/.ssh/xcr_build -p 22 macbuild@192.0.2.10macOS n’inclut pas toujours ssh-copy-iden standard. Si les informations fournies autorisent l’authentification par mot de passe, vous pouvez utiliser la commande SSH standard ci-dessous. Si seules les clés sont autorisées, faites approuver la clé publique selon la procédure prévue ; n’essayez pas le mot de passe à répétition.
cat ~/.ssh/xcr_build.pub | ssh -p 22 macbuild@192.0.2.10 \
'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'Après la réinstallation d’un nœud, si un changement de clé d’hôte est signalé, vérifiez l’historique de réinstallation et la nouvelle empreinte avant de mettre à jour votre entrée locale. Ne masquez pas l’anomalie en désactivant la vérification de l’hôte.
Ajoutez la configuration suivante dans le fichier local ~/.ssh/config. L’alias vous évite de mémoriser l’adresse du nœud. Si elle change, modifiez-la uniquement ici : vos scripts continueront d’utiliser xcr-build.
Host xcr-build
HostName 192.0.2.10
User macbuild
Port 22
IdentityFile ~/.ssh/xcr_build
IdentitiesOnly yes
ServerAliveInterval 30
ServerAliveCountMax 3Effectuez une première vérification en lecture seule : contrôlez la version réelle du système, la version de Xcode sélectionnée et l’espace disque disponible. Vérifiez l’environnement avant d’installer des dépendances ou d’enregistrer un runner, afin d’éviter d’intégrer une version incorrecte à votre pipeline.
ssh xcr-build
sw_vers
xcode-select -p
xcodebuild -version
df -h "$HOME"Pour configurer des certificats de signature, vérifier les autorisations du trousseau ou consulter les réglages de Xcode, le bureau à distance est souvent plus simple que de tâtonner avec des commandes. Une fois les vérifications terminées, automatisez les étapes stables en ligne de commande.
Sur votre Mac, ouvrez « Partage d’écran » et saisissez l’adresse et le port du bureau indiqués dans les informations de livraison. Vous pouvez aussi saisir l’adresse VNC fournie dans le Finder, via « Aller > Se connecter au serveur ».
Les identifiants du bureau peuvent différer de ceux de SSH. Utilisez les champs correspondants indiqués dans la console ; un fichier de clé SSH ne remplace pas le mot de passe VNC.
Sur les autres systèmes, utilisez un client VNC compatible avec le mode d’authentification fourni. Renseignez l’hôte, le port et les informations d’authentification. N’exposez pas vous-même le bureau sur un réseau public.
Si les instructions de livraison autorisent l’accès au service VNC local du nœud via SSH, vous pouvez créer un tunnel. L’exemple ci-dessous ne s’applique que si le service distant écoute sur 127.0.0.1:5900 ; utilisez le port indiqué dans les informations de livraison.
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:5901:127.0.0.1:5900 xcr-buildLaissez ce terminal ouvert, puis connectez votre client VNC local à 127.0.0.1:5901. Le port local est lié uniquement à l’interface de bouclage. À la fin de la session de bureau, appuyez sur Control-C pour fermer le tunnel.
Vérifiez que Xcode démarre et que la version attendue est sélectionnée ; que le compte de build peut accéder au certificat de signature et à sa clé privée ; et que le profil d’approvisionnement correspond au Bundle Identifier, à l’équipe et au mode d’exportation du projet. Ne faites pas apparaître le mot de passe du certificat dans vos captures d’écran.
Migrez dans cet ordre : données, chaîne d’outils, intégration CI. Effectuez d’abord un archivage manuel à partir du même commit, puis confiez les builds au runner. Ne changez pas simultanément de version de Xcode, de dépendances et de stratégie de signature.
Placez le code source et les fichiers de verrouillage dans un répertoire de travail dédié. Commencez par simuler le transfert avec rsync et vérifiez le chemin cible. Ne synchronisez pas tout votre répertoire utilisateur et n’envoyez pas par défaut vos certificats, clés privées ou fichiers d’environnement locaux.
DerivedData est un cache que vous pouvez reconstruire. Réutilisez-le uniquement si les versions de Xcode, les dépendances et l’environnement source sont compatibles. En cas de problème de chemin ou de cache de modules, privilégiez un nettoyage suivi d’un build à froid.
Vérifiez les versions avec xcode-select -p et xcodebuild -version . Pour changer de version, utilisez un chemin Xcode qui existe réellement sur le nœud, puis vérifiez le SDK requis par le projet.
Conservez Podfile.lock, Package.resolved et Gemfile.lock. Utilisez CocoaPods, SPM et Fastlane dans les versions verrouillées par le projet. Importez séparément les certificats et les profils d’approvisionnement, puis vérifiez les autorisations d’accès à la clé privée.
Créez les informations d’enregistrement d’un runner auto-hébergé dans le projet GitHub ou GitLab, puis suivez les étapes macOS indiquées par la plateforme. Le jeton d’enregistrement ne sert qu’à une configuration contrôlée : ne l’ajoutez ni au dépôt ni aux journaux de build.
Attribuez au runner des étiquettes correspondant à son usage et à sa chaîne d’outils, par exemple macosetios-build. Au départ, autorisez les tâches de signature uniquement depuis des branches de confiance et limitez le nombre de tâches simultanées. Ajustez ensuite selon la mémoire, l’espace disque et les journaux d’exécution.
rsync -avzn --exclude '.env' --exclude '.env.*' \
--exclude 'DerivedData/' ./MyApp/ xcr-build:~/builds/MyApp/
rsync -avz --exclude '.env' --exclude '.env.*' \
--exclude 'DerivedData/' ./MyApp/ xcr-build:~/builds/MyApp/La première commande inclut -net affiche uniquement les changements prévus. Vérifiez-les avant d’exécuter la seconde commande. L’exemple n’utilise pas --deleteafin d’éviter de supprimer par erreur des fichiers distants lors de la première migration. Si votre projet contient d’autres répertoires de clés, ajoutez-les d’abord aux exclusions.
Consignez le commit source, la version de Xcode, les fichiers de verrouillage des dépendances, le Scheme, la configuration d’exportation, les étiquettes du runner et le chemin des artefacts. Vérifiez séparément un build à froid et un build incrémental avant de décider si le cache doit être copié. Les commandes de cette page ne constituent pas un test de performances et ne garantissent pas de durée de build.
En cas de problème, distinguez le protocole de connexion, l’environnement d’exécution et le cache de build. Préciser à quel niveau survient l’échec facilite le diagnostic, contrairement à un simple « impossible de se connecter à la machine ».
Nos six nœuds sont répartis sur trois configurations. Pour un bureau à distance interactif, privilégiez la proximité avec les principaux utilisateurs, puis vérifiez les chemins vers le dépôt de code, les téléchargements de dépendances et l’envoi des artefacts. Le fuseau horaire de l’équipe peut aider à présélectionner un nœud, mais ne remplace pas un test réseau réel.
SG · UTC+8
Adapté aux équipes dont les horaires de collaboration correspondent principalement aux jours ouvrés d’Asie du Sud-Est. Testez d’abord l’interactivité du bureau depuis votre site, puis les téléchargements de dépendances et l’envoi des artefacts.
JP · UTC+9
Adapté aux équipes qui travaillent principalement aux horaires japonais. Demandez d’abord aux personnes qui déboguent dans l’interface graphique de tester la connexion, puis planifiez les tâches automatisées.
KR · UTC+9
Adapté aux équipes qui travaillent principalement aux horaires coréens. Vérifiez que le réseau de l’entreprise autorise l’accès aux ports fournis et que les longues sessions SSH restent stables.
HK · UTC+8
Adapté aux équipes dont les horaires de collaboration se concentrent sur le sud de la Chine et les régions voisines. Testez séparément la réactivité du bureau, la récupération du code et le transfert du cache ; un seul ping ne suffit pas à tirer une conclusion.
US-E · UTC−5 / UTC−4
Adapté aux horaires de travail de la côte Est nord-américaine et à la collaboration entre fuseaux horaires. L’heure d’été y est appliquée : indiquez toujours le fuseau horaire dans les consignes de passation, pas seulement l’heure.
US-W · UTC−8 / UTC−7
Adapté aux horaires de travail de la côte Ouest nord-américaine. Pour les équipes réparties sur plusieurs fuseaux horaires, un archivage nocturne peut s’enchaîner avec les commits de la journée de l’autre équipe ; limitez malgré tout les tâches de signature simultanées.
Les nœuds fonctionnent toute l’année, 365 jours par an. Consultez la console pour connaître leur disponibilité en temps réel. Pour diagnostiquer un problème de connexion, ouvrez un ticket dans la console en indiquant le nœud, sa configuration, le protocole utilisé, le message d’erreur exact et les étapes pour reproduire le problème. Masquez uniquement les identifiants et ne supprimez pas les détails utiles au diagnostic.
Visez cinq minutes pour la première connexion : vérifiez l’hôte, testez SSH et ouvrez le bureau. Une fois le réseau et l’authentification validés, migrez l’environnement de build. La validation complète du pipeline doit être planifiée selon les besoins du projet.
À partir de $21.7/jour. Paiement par USDT-TRC20 ou Visa / Mastercard / Amex via Stripe, en dollars américains. Les moyens de paiement disponibles dépendent de la réponse de l’interface du prestataire.