Guide

Faire tourner un pipeline CI/CD iOS sur votre propre machine

La plupart des conseils sur la CI iOS optimisent la mauvaise chose. L’étape de build est rarement celle qui consomme les minutes. Voici ce qui change vraiment la donne sur un vrai pipeline, et comment un matériel dédié modifie le calcul.

Où partent vraiment les minutes

Sur un runner hébergé, un job iOS typique passe une grande part de son temps avant de compiler la moindre ligne de votre code. Il résout et télécharge les dépendances, remplit un dossier DerivedData vide, installe les outils et démarre un simulateur. Ce travail se répète à chaque exécution, car la machine est détruite ensuite.

Sur une machine dédiée, ce travail est en grande partie déjà fait. Dans notre benchmark de l’app iOS Wikipedia, un build propre sur un M6 mini a été 53 % plus rapide que sur le runner standard de GitHub. Un job CI typique est passé de 269 secondes à 27. Le Mac dédié avait gardé son dossier de build et n’a recompilé que ce qui avait changé.

Un pipeline à copier

Répartissez le travail. Le lint, les tests des paquets Swift partagés et l’automatisation des releases peuvent tourner sous Linux. Ne mettez sur le Mac que le travail sur simulateur et sur appareil.
Mettez en cache les bons chemins. DerivedData, SwiftPM, CocoaPods et les Gems. Sur une machine dédiée, ils persistent gratuitement.
Confiez les tâches ennuyeuses à fastlane. Les lanes de build, de test, de captures d’écran et d’envoi vous donnent les mêmes commandes en local et en CI.
Gardez une signature prévisible. fastlane match avec un dépôt privé de certificats reste l’approche la plus fiable. MacRun ne gère pas la signature pour vous. Rien ne vous surprend donc non plus de ce côté.
Allégez la matrice. Les matrices complètes d’appareils et de versions d’OS vont sur main et dans les builds de nuit. Pas sur chaque pull request.

Exemple de workflow

name: iOS
on: [pull_request]

jobs:
  test:
    runs-on: [self-hosted, macOS, macrun-unit-01]
    steps:
      - uses: actions/checkout@v4
      - run: sudo xcodes select 26.6
      - run: bundle install
      - run: bundle exec fastlane test

Comme le runner est dédié, il n’y a pas d’étape de restauration du cache ici. Les dépendances et le DerivedData de l’exécution précédente sont déjà sur le disque.

Ce que cela ne règle pas

Un matériel dédié ne corrige pas une suite de tests lente, un graphe de modules qui force des rebuilds complets, ni des tests de simulateur instables. Il supprime la taxe de préparation répétée et le compteur à la minute. Le reste demande toujours du travail d’ingénierie de votre côté.

Questions fréquentes

Comment accélérer les builds iOS dans GitHub Actions ?

Supprimez la préparation répétée avant d’optimiser la compilation. Conservez les caches DerivedData, SwiftPM et CocoaPods. Passez le travail hors Mac sur des runners Linux. Allégez les matrices d’appareils sur les pull requests, et figez une version de Xcode. Sur du matériel dédié, les caches persistent automatiquement entre les exécutions.

Puis-je utiliser fastlane sur un runner macOS self-hosted ?

Oui. fastlane, CocoaPods, Ruby et Node sont préinstallés sur les machines MacRun, et vous les lancez exactement comme en local. La signature avec fastlane match fonctionne comme sur n’importe quel Mac.

MacRun gère-t-il la signature de code pour moi ?

Non, et c’est voulu. Vous gardez la main sur vos certificats et vos profils de provisionnement, en général avec fastlane match et votre propre dépôt privé. Nous fournissons la machine, pas un service de signature géré.

Puis-je lancer des tests UI iOS sur un runner dédié ?

Oui. Les simulateurs fonctionnent normalement. Comme la machine n’est pas recyclée, l’état de démarrage des simulateurs et les données dérivées restent chauds entre les exécutions. Cela retire en général plusieurs minutes à un job de tests UI.