Devin a désormais accès à des machines virtuelles macOS. Il peut donc maintenant compiler et tester des applications iOS et macOS.
Si vous utilisez un déploiement Dedicated SaaS, contactez votre account team pour activer les VM macOS.
runs-on de votre blueprint indique à Devin sur quelle plateforme effectuer le build et l’exécution, et chaque plateforme dispose de son propre snapshot.
Les principales différences par rapport à Linux concernent le shell, l’organisation du système de fichiers et le package manager :
Démarrer une session macOS
- Blueprint : ajoutez
runs-on: macos afin que le snapshot du repo soit construit pour macOS (voir ci-dessous).
- Slack : utilisez la bang command
!mac pour démarrer une session sur une VM macOS.
- API : définissez
platform: "macos" lors de la création d’une session, d’une planification ou d’une automation. Consultez l’API reference.
Rédiger des blueprints macOS
runs-on: macos au niveau supérieur :
Pour builder le même repository sur plusieurs plateformes, écrivez chaque plateforme dans un document YAML distinct, séparé par ---. Chaque document déclare son propre libellé runs-on. Consultez l’encadré Multi-document YAML du guide des blueprints pour plus de contexte sur ce format.
Chaque document produit un build du snapshot distinct pour sa plateforme. Les sessions démarrent à partir du snapshot spécifique à la plateforme.
Le YAML de premier niveau doit être un mapping, et non une séquence. Si vous écrivez l’exemple ci-dessus sous la forme d’une seule liste (- runs-on: default / - runs-on: macos), le backend la rejettera. Utilisez le séparateur --- présenté ci-dessus.
runs-on correspond à une configuration de machine enregistrée sur votre compte :
Vous pouvez spécifier runs-on sous forme de chaîne ou de liste :
La syntaxe de liste exécute les mêmes commandes sur toutes les plateformes de la liste. Ne l’utilisez que lorsque les commandes sont réellement multiplateformes (par exemple npm install). Pour les commandes propres à une plateforme (comme apt-get sous Linux ou brew sous macOS), utilisez plutôt le format multi-document. Sélectionner une version de Xcode
xcode-select. Pour utiliser une autre version installée le temps d’une seule commande, définissez DEVELOPER_DIR :
Utilisez /usr/bin/xcodebuild (le shim qui respecte DEVELOPER_DIR) plutôt qu’un xcodebuild résolu depuis le dossier Contents/Developer/usr/bin d’un Xcode spécifique présent dans le PATH : ce dernier renvoie sa propre version sans tenir compte de DEVELOPER_DIR.
Vous pouvez aussi changer la valeur par défaut pour toute la session :
Indiquez celle dont vous avez besoin dans votre blueprint afin que chaque session démarre avec la bonne chaîne d’outils.
Comportement des sessions macOS
sed -i exige un argument (sed -i ''), et les outils GNU comme gsed, gdate et greadlink proviennent de la formule Homebrew coreutils.
Les repositories sont clonés dans /Users/devin/repos/<repo-name>, et les fichiers que vous uploadez dans une session sont écrits dans /Users/devin/.files/.
Les secrets sont exposés sous forme de variables d’environnement pendant les sessions ($SECRET_NAME), comme sous Linux. C’est ainsi que vous fournissez les API keys App Store Connect, les credentials de signature ou les tokens de registre privé :
Mise en veille et sortie de veille des sessions
Préchauffer les caches de build
maintenance dans environment.yml pour préchauffer le cache.
Les packages Swift résolus, les CocoaPods et le dossier DerivedData sont conservés dans le snapshot : les nouvelles sessions démarrent donc à partir d’un build incrémental.
Les builds qui récupèrent des dépendances depuis CocoaPods, Swift Package Manager, Firebase ou un registre privé nécessitent que ces hôtes soient joignables. Si votre organisation applique une politique réseau restrictive, vérifiez que la liste d’autorisation macOS couvre les mêmes registres que vos builds Linux. Les deux se configurent séparément, et une entrée manquante se traduit généralement par un échec de résolution de dépendances ou une erreur TLS en plein milieu d’un build.
Les VM macOS ne disposent pas de virtualisation matérielle imbriquée : un environnement d’exécution de containers doit donc se replier sur l’émulation logicielle de QEMU (TCG). Colima le détecte et bascule automatiquement en mode émulation :
La VM met deux à quatre minutes à devenir utilisable, et le premier démarrage peut expirer en attente de SSH pendant que l’invité émulé initialise le réseau : relancez donc colima start en cas d’échec. Les containers s’exécutent ensuite environ 15 à 25 fois plus lentement sur CPU qu’en natif, avec quelques secondes de démarrage chacun ; les pulls, eux, se font à la vitesse du réseau de l’hôte. C’est acceptable pour un container de linting ou d’empaquetage, mais pénible pour de la compilation. Pour les travaux reposant fortement sur les containers, utilisez une session Linux ou faites pointer la session macOS vers un démon Docker distant.
N’installez Xcode dans un blueprint qu’en cas de nécessité
DEVELOPER_DIR ou xcode-select. Si vous avez besoin d’une autre version ou d’une bêta, vous pouvez stocker un Apple ID sous forme de secret et laisser le blueprint télécharger cette version, au prix d’un build bien plus lent.
Les builds sont beaucoup plus lents lors de la première session suivant une reconstruction de snapshot. DerivedData a été reconstruit de zéro. Ajoutez une étape build-for-testing à maintenance pour que le snapshot embarque un build déjà à chaud.
xcodebuild sélectionne la mauvaise chaîne d’outils. Vérifiez xcode-select -p et définissez explicitement DEVELOPER_DIR dans l’étape du blueprint.
Une destination est introuvable. Exécutez xcrun simctl list devices available pour voir ce que les environnements d’exécution installés fournissent réellement, puis alignez le nom et l’OS de -destination en conséquence.
La résolution des dépendances se bloque ou échoue avec une erreur TLS. L’hôte est probablement absent de la liste d’autorisation réseau de votre organisation pour macOS. Consultez Accès réseau. 
