Runners hébergés sur macOS

{{< details >}}

• Édition : GitLab Premium, GitLab Ultimate
• Offre : GitLab.com
• Statut : Version bêta

{{< /details >}}

Les runners hébergés sur macOS fournissent un environnement macOS à la demande, entièrement intégré avec GitLab CI/CD. Vous pouvez utiliser ces runners pour compiler, tester et déployer des applications pour l'écosystème Apple (macOS, iOS, watchOS, tvOS). Notre section Mobile DevOps fournit des fonctionnalités, de la documentation et des conseils sur la compilation et le déploiement d'applications mobiles pour iOS.

Les runners hébergés sur macOS sont en version bêta et disponibles pour les programmes open source et les clients disposant des plans Premium et Ultimate. La disponibilité générale des runners hébergés sur macOS est proposée dans l'epic 8267.

Consultez la liste des problèmes connus et des contraintes d'utilisation qui affectent les runners hébergés sur macOS avant de les utiliser.

Types de machines disponibles pour macOS {#machine-types-available-for-macos}

GitLab propose le type de machine suivant pour les runners hébergés sur macOS. Pour compiler pour une cible x86-64, vous pouvez utiliser Rosetta 2 pour émuler un environnement Intel x86-64.

Images macOS prises en charge {#supported-macos-images}

Contrairement à nos runners hébergés sur Linux, où vous pouvez exécuter n'importe quelle image Docker, GitLab fournit un ensemble d'images VM pour macOS.

Vous pouvez exécuter votre compilation dans l'une des images suivantes, que vous spécifiez dans votre fichier .gitlab-ci.yml. Chaque image exécute une version spécifique de macOS et de Xcode.

Si aucune image n'est spécifiée, le runner macOS utilise macos-15-xcode-16.

Politique de mise à jour des images pour macOS {#image-update-policy-for-macos}

Les images et les composants installés sont mis à jour à chaque release GitLab, afin de maintenir les logiciels préinstallés à jour. GitLab prend généralement en charge plusieurs versions de logiciels préinstallés. Pour plus d'informations, consultez la liste complète des logiciels préinstallés.

Les versions majeures et mineures de macOS et de Xcode sont disponibles dans le jalon suivant la release Apple.

Une nouvelle image de version majeure est d'abord disponible en version bêta, et devient généralement disponible avec la release de la première version mineure. Étant donné que seules deux images généralement disponibles sont prises en charge à la fois, l'image la plus ancienne est dépréciée et sera supprimée après trois mois conformément au cycle de vie des images prises en charge.

Lorsqu'une nouvelle version majeure est généralement disponible, elle devient l'image par défaut pour tous les jobs macOS.

Exemple de fichier .gitlab-ci.yml {#example-gitlab-ciyml-file}

L'exemple de fichier .gitlab-ci.yml suivant montre comment commencer à utiliser les runners hébergés sur macOS :

.macos_saas_runners:
  tags:
    - saas-macos-medium-m1
  image: macos-14-xcode-15
  before_script:
    - echo "started by ${GITLAB_USER_NAME} / @${GITLAB_USER_LOGIN}"

build:
  extends:
    - .macos_saas_runners
  stage: build
  script:
    - echo "running scripts in the build job"

test:
  extends:
    - .macos_saas_runners
  stage: test
  script:
    - echo "running scripts in the test job"

Signature de code des projets iOS avec fastlane {#code-signing-ios-projects-with-fastlane}

Avant de pouvoir intégrer GitLab aux services Apple, installer sur un appareil ou déployer sur l'Apple App Store, vous devez signer le code de votre application.

Chaque image VM de runner sur macOS inclut fastlane, une solution open source visant à simplifier le déploiement d'applications mobiles.

Pour savoir comment configurer la signature de code pour votre application, consultez les instructions dans la documentation Mobile DevOps.

Sujets connexes :

• Apple Developer Support - Code Signing
• Code Signing Best Practice Guide
• Guide d'authentification fastlane avec les services Apple

Optimisation de Homebrew {#optimizing-homebrew}

Par défaut, Homebrew vérifie les mises à jour au début de chaque opération. Homebrew suit un cycle de release qui peut être plus fréquent que le cycle de release des images macOS de GitLab. Cette différence de cycles de release peut entraîner des délais supplémentaires pour les étapes qui appellent brew pendant que Homebrew effectue ses mises à jour.

Pour réduire le temps de compilation lié aux mises à jour involontaires de Homebrew, définissez la variable HOMEBREW_NO_AUTO_UPDATE dans .gitlab-ci.yml :

variables:
  HOMEBREW_NO_AUTO_UPDATE: 1

Optimisation de CocoaPods {#optimizing-cocoapods}

Si vous utilisez CocoaPods dans un projet, vous devriez envisager les optimisations suivantes pour améliorer les performances de CI.

CocoaPods CDN

Vous pouvez utiliser l'accès au réseau de distribution de contenu (CDN) pour télécharger des packages depuis le CDN au lieu de devoir cloner l'intégralité d'un dépôt de projet. L'accès CDN est disponible dans CocoaPods 1.8 ou version ultérieure et est pris en charge par tous les runners GitLab hébergés sur macOS.

Pour activer l'accès CDN, assurez-vous que votre Podfile commence par :

source 'https://cdn.cocoapods.org/'

Use GitLab caching

Utilisez la mise en cache dans les packages CocoaPods dans GitLab pour n'exécuter pod install que lorsque les pods changent, ce qui peut améliorer les performances de compilation.

Pour configurer la mise en cache pour votre projet :

1. Ajoutez la configuration cache à votre fichier .gitlab-ci.yml :

   yamlCopy

   cache:
     key:
       files:
        - Podfile.lock
   paths:
     - Pods
   

2. Ajoutez le plugin cocoapods-check à votre projet.

3. Mettez à jour le script du job pour vérifier les dépendances installées avant d'appeler pod install :

   shellCopy

   bundle exec pod check || bundle exec pod install
   

Include pods in source control

Vous pouvez également inclure le répertoire des pods dans le contrôle de code source. Cela élimine la nécessité d'installer des pods dans le cadre du job CI, mais augmente la taille globale du dépôt de votre projet.

Problèmes connus et contraintes d'utilisation {#known-issues-and-usage-constraints}

• Si l'image VM n'inclut pas la version spécifique du logiciel dont vous avez besoin pour votre job, le logiciel requis doit être récupéré et installé. Cela entraîne une augmentation du temps d'exécution du job.
• Il n'est pas possible d'utiliser votre propre image OS.
• Le trousseau pour l'utilisateur gitlab n'est pas accessible publiquement. Vous devez créer un trousseau à la place.
• Les runners hébergés sur macOS s'exécutent en mode sans interface graphique (headless). Les charges de travail nécessitant des interactions avec l'interface utilisateur, telles que testmanagerd, ne sont pas prises en charge.
• Les performances des jobs peuvent varier entre les exécutions, car les puces Apple silicon disposent de cœurs d'efficacité et de performances. Vous ne pouvez pas contrôler l'allocation des cœurs ni la planification, ce qui peut entraîner des incohérences.
• La disponibilité des machines macOS bare metal AWS utilisées pour les runners hébergés sur macOS est limitée. Les jobs peuvent subir des temps d'attente prolongés lorsqu'aucune machine n'est disponible.
• Les instances de runners hébergés sur macOS ne répondent parfois pas aux requêtes, ce qui entraîne le blocage des jobs jusqu'à ce que la durée maximale du job soit atteinte.
• macOS utilise par défaut un système de fichiers insensible à la casse. Ce comportement peut entraîner des erreurs inattendues si vous avez des chemins de fichiers en double qui ne diffèrent que par la casse. Ces chemins en double peuvent se trouver dans l'arborescence de travail Git ou dans les refs Git où les branches et les tags sont stockés.