Lancez votre premier pipeline de build iOS

Si xcodesn’est pas encore installé sur la machine, installez-le selon la procédure approuvée par votre équipe. Pour installer une version donnée, utilisez un paquet Xcode local obtenu légalement et compatible avec les exigences du projet. Les variables ci-dessous, XCODE_VERSION et XCODE_XIP correspondent respectivement au numéro de version vérifié et au chemin absolu du paquet d’installation. N’intégrez pas les étapes interactives de l’installation à un job de build sans intervention.

XCODE_APP doit pointer vers le chemin réel de l’application installée. Pour la CI, définissez de préférence DEVELOPER_DIRdans l’environnement du job afin d’éviter que plusieurs jobs ne se disputent la sélection globale. Si vous devez vraiment changer les outils par défaut du système, exécutez sudo xcode-select --switch "$XCODE_APP/Contents/Developer"puis vérifiez à nouveau xcodebuild -version.

Lancez une première fois la version de Xcode sélectionnée et terminez la préparation des composants nécessaires. Vous pouvez utiliser l’interface graphique à distance, puis installer le runtime requis dans les réglages des composants de Xcode. Exécutez xcrun simctl list devices available, choisissez un simulateur correspondant à vos tests, démarrez-le une fois en mode interactif et attendez qu’il soit prêt avant de lancer un test minimal. L’archivage d’une app pour un appareil physique et les tests sur simulateur sont deux étapes distinctes. Ne confondez pas l’absence d’un runtime avec un problème de chaîne d’outils d’archivage.

Au début des journaux CI, vérifiez au minimum la version de Xcode, la liste des SDK et l’identifiant du commit. Après un changement de version de Xcode, régénérez la clé de cache et vérifiez les dépendances tierces, la signature et l’exportation. Modifier uniquement les tags du runner sans vérifier le chemin réel des outils ne garantit pas un environnement de build cohérent.

GitLab Runner : vérifier les tags et l’exécuteur

Dans les paramètres du projet, créez un runner de projet, préparez son jeton d’authentification et définissez les tags macos,arm64etios-archive . Placez temporairement l’URL de l’instance et le jeton d’authentification dans GITLAB_URLetGITLAB_RUNNER_TOKEN, puis enregistrez un exécuteur shell sous un compte dédié aux builds. Une fois l’opération terminée, supprimez la variable temporaire contenant le jeton.

Dans les variables du projet, définissez les valeurs réelles de IOS_WORKSPACE et IOS_SCHEME, puis préparez la signature comme indiqué à la section suivante. Cet exemple réalise uniquement l’archivage : il ne comprend ni exportation ni téléversement. La conservation des artefacts pendant 7 jours n’est qu’une valeur d’exemple, que vous pouvez adapter à la politique de conservation de votre équipe. N’ajoutez pas de certificats, de clés privées ni de trousseaux temporaires aux artefacts.

GitHub Actions : un job à la fois par processus runner

Téléchargez le programme compatible avec macOS ARM64 en suivant les instructions d’installation du runner fournies dans les paramètres du dépôt, puis ouvrez le répertoire décompressé. Définissez REPOSITORY_URL sur l’URL du dépôt actuel etRUNNER_TOKEN sur le jeton d’enregistrement utilisé pour cette opération. Les tags doivent figurer à la fois dans la configuration d’enregistrement et dans le workflow afin que les jobs soient dirigés vers la bonne chaîne d’outils.

Commencez par définir le chemin des outils, le workspace et le scheme dans les variables du dépôt. Cet exemple se déclenche manuellement pour faciliter la validation initiale de l’environnement. N’exposez pas directement un runner contenant des identifiants de signature à du code externe non fiable. Un processus runner ne traite qu’un job à la fois ;concurrency limite également l’exécution des workflows d’un même groupe, mais ne constitue pas une limite des ressources à l’échelle de la machine.

Une fois les tests validés, configurez l’exécution permanente à l’aide du script de service fourni avec le programme téléchargé, puis vérifiez que le compte du service est le même que celui utilisé pour les tests manuels. Si la signature est configurée sous un compte et que le service tourne sous un autre, le build interactif peut réussir alors que la CI ne trouve ni le certificat ni le profil de provisionnement.

Utilisez un trousseau dédié aux tâches automatisées et injectez son mot de passe via une variable secrète protégée de la CI. Après l’importation du certificat, autorisez uniquement les outils de signature qui en ont besoin ; ne donnez pas accès à la clé privée à toutes les applications. Les commandes ci-dessous vérifient que l’utilisateur actuel voit une identité de signature valide, mais ne garantissent pas que le profil de provisionnement, la configuration d’exportation et les réglages du projet correspondent parfaitement.

L’emplacement des profils de provisionnement peut varier selon la version de Xcode. Fiez-vous au chemin réellement utilisé par la chaîne d’outils active. Après l’importation, vérifiez la date d’expiration, l’identifiant de l’app et le type de signature. Si l’archivage réussit mais que l’exportation échoue, vérifiez en priorité la méthode d’exportation, l’identifiant de l’équipe et les correspondances des profils, plutôt que de réinstaller Xcode sans cesse.

Si votre équipe utilise déjà fastlane match, conservez le dépôt de certificats chiffré et les règles d’accès existants. Pour la phase de validation, utilisez bundle exec fastlane match appstore --readonlyafin de récupérer d’abord les éléments de signature existants, sans risquer de modifier les certificats de l’équipe depuis la machine de build. Gérez séparément les identifiants d’accès au dépôt, le mot de passe de déchiffrement et celui du trousseau. Ne mettez les variables de signature de production à disposition que des branches protégées ou de jobs manuels contrôlés.

À la fin du job, supprimez les fichiers temporaires et verrouillez le trousseau temporaire. Ne conservez dans les journaux que les codes d’erreur et les résultats nécessaires ; n’y affichez ni clés privées, ni mots de passe de certificats, ni jetons d’enregistrement, ni valeurs complètes des variables secrètes. Un Mac physique dédié isole les ressources, mais les autorisations des identifiants du projet doivent toujours respecter le principe du moindre privilège.

Exécutez diskutil list et df -hpour vérifier la capacité et le point de montage. N’effacez pas et ne partitionnez pas un disque dont vous ne connaissez pas la nature. Créez un répertoire de cache accessible en écriture par le compte de build et testez la lecture et l’écriture avec un petit fichier. Vérifiez le comportement du montage après redémarrage avant de faire utiliser le nouveau chemin au runner permanent.

Avant la migration, cessez d’accepter de nouveaux jobs et attendez la fin des archivages et signatures en cours. DerivedData est un cache régénérable : mieux vaut le recréer au nouvel emplacement que copier un ancien cache potentiellement en cours d’écriture. L’exemple utilise l’option explicite -derivedDataPathet ne nécessite pas de déplacer tout le répertoire utilisateur vers le volume ajouté.

Avant l’exécution, définissez BUILD_VOLUME sur un point de montage dont l’accès en écriture a été vérifié.CACHE_KEY doit distinguer le dépôt, la version de Xcode et la configuration de build ;BUILD_ID doit identifier le job en cours de manière unique pour éviter que plusieurs jobs n’écrasent leurs archives. Les jobs exécutés en parallèle ne doivent pas partager le même répertoire DerivedData accessible en écriture.

Commencez par un build sans cache, puis observez les accès au cache et la consommation du disque lors des jobs suivants. Définissez des règles de conservation distinctes pour les archives, les données des simulateurs et le cache des dépendances. Avant toute suppression, vérifiez qu’aucun job n’utilise encore ces fichiers. Enregistrez les artefacts de build séparément dans un stockage géré par votre équipe ; le cache de la machine ne peut pas servir d’unique sauvegarde. Avant la fin de la location, exportez vos données et vérifiez que la sauvegarde est lisible.