GitHub Actions Runner macOS 14 retiré : comment migrer la CI ? 2026

Le retrait est effectif : la migration du Runner macOS 14 de GitHub Actions doit être vérifiée

Le 2 novembre 2026, GitHub a retiré les labels macos-14, macos-14-large et macos-14-xlarge (annonce officielle). Les workflows qui en dépendent ne doivent donc plus compter sur ces labels : choisissez un Runner encore documenté selon les besoins réels en macOS, Xcode et architecture, puis éprouvez-le à l’écart de la livraison avant toute bascule. Remplacer l’ancien label par latest sans validation ne constitue pas une stratégie de migration.

Cette démarche concerne les équipes Apple qui ont encore des jobs utilisant l’un des trois labels retirés et doivent rétablir ou déplacer leurs builds.
Elle s’adresse aussi aux ingénieurs CI chargés de vérifier les tests, les signatures et les archives sur le nouvel environnement.
Les responsables DevOps ou plateforme peuvent s’en servir pour définir des critères de validation et de retour arrière.

Dernière vérification le 8 novembre 2026 ; les informations de retrait et les options de migration ont été vérifiées dans l’annonce GitHub, la documentation des Runner hébergés et le dépôt des images Runner. La disponibilité et le contenu des images étant susceptibles d’évoluer, vérifiez-les à nouveau au moment de modifier le workflow.

Inventorier les labels et les capacités réellement disponibles

Le retrait concerne précisément les trois labels cités dans l’annonce. Il ne signifie pas que toutes les images macOS, toutes les tailles de Runner ou toutes les versions de Xcode ont changé de la même façon. Le choix d’un substitut doit s’appuyer sur la documentation courante des Runner hébergés et sur les images effectivement publiées, plutôt que sur une équivalence supposée entre numéros de système.

Commencez par rechercher les références concernées dans les fichiers de workflow, les fichiers appelés par réutilisation et les matrices. Un label peut être défini directement avec runs-on, généré par une variable ou fourni dans une matrice ; une recherche limitée au fichier principal peut donc manquer des jobs affectés. Il faut aussi vérifier les workflows déclenchés par publication, les tâches planifiées et les branches de maintenance, pas seulement le parcours de validation des changements.

Les journaux des exécutions historiques aident à établir une référence : relevez le label demandé, les versions de Xcode et des outils, l’architecture réellement observée, les destinations Simulator, les dépendances restaurées et les artefacts produits. Ces journaux décrivent l’environnement précédent, mais ne prouvent pas qu’un Runner de remplacement fournit les mêmes logiciels ou la même architecture.

Avant de modifier les workflows, comparez la liste des labels disponibles avec la documentation GitHub actuelle et le dépôt des images Runner. La documentation indique les Runner proposés et leurs caractéristiques, tandis que le dépôt suit les images et les logiciels installés. Ces sources sont complémentaires : une suggestion de migration dans une annonce ne suffit pas à démontrer qu’un label donné convient à chaque projet.

Pour les workflows utilisant des matrices, gardez la possibilité de lancer les mêmes tâches sur plusieurs environnements dans un essai contrôlé. La documentation GitHub sur les variations de jobs explique comment organiser ces exécutions. La matrice doit toutefois rester limitée aux combinaisons utiles au projet : multiplier les variantes sans critère de validation rend les résultats plus difficiles à interpréter.

Évaluer la compatibilité du système et de Xcode

Un Runner portant une version récente de macOS n’est pas automatiquement compatible avec le projet. Le système, Xcode, les SDK, les outils de compilation et les dépendances forment un ensemble : une mise à jour de l’image peut modifier un seul de ces éléments, mais suffire à faire échouer un script, une extension ou une étape d’archivage.

Établissez d’abord les contraintes explicites du dépôt. Repérez la version de Xcode sélectionnée dans le workflow, les paramètres de destination, les versions minimales ciblées par le projet, ainsi que les outils installés ou téléchargés pendant le job. Distinguez les contraintes requises pour compiler de celles qui ne servent qu’à tester ou à publier. Cette séparation aide à identifier si un échec vient de la version de macOS, du compilateur, du SDK ou d’une dépendance externe.

Pour chaque version envisagée, consultez les notes de publication officielles de Xcode 26 et les exigences système d’Apple pour Xcode. Les notes de publication permettent de contrôler les changements et les problèmes connus de la version, tandis que les exigences système servent à vérifier les systèmes compatibles. Une préversion et une version stable ne doivent pas être considérées comme interchangeables : si le projet exige une version stable, un essai sur une version bêta ne valide pas le parcours de publication.

Il faut ensuite confirmer la version de Xcode réellement disponible sur le Runner choisi, dans les journaux d’exécution, plutôt que de la déduire du label. Consignez la sortie des commandes de diagnostic déjà utilisées par le projet, puis contrôlez que les outils appelés explicitement par les scripts pointent vers la version attendue. Si un job sélectionne lui-même une version de Xcode, vérifiez également que cette sélection reste valide dans la nouvelle image.

Pour les projets qui construisent une application créative ou multimédia, le contrôle ne s’arrête pas à la compilation du code. Une application audio ou vidéo peut dépendre de frameworks système, de formats de ressources ou d’étapes d’export qui ne sont exercés que dans un test ciblé. Les équipes de design peuvent également devoir valider la génération des aperçus, l’intégration de ressources et les outils d’export, même si ces étapes n’apparaissent pas dans le build minimal. La bonne version de Xcode est donc celle qui satisfait le flux réel, pas simplement celle qui démarre sans erreur.

Vérifier l’architecture et les dépendances natives

L’architecture est un critère de migration distinct de la version de macOS. Un job peut compiler sur une nouvelle image tout en rencontrant ensuite un binaire indisponible, un paquet précompilé incompatible ou un script qui suppose un environnement Intel. À l’inverse, le fait qu’un outil soit universel ne garantit pas que toutes ses dépendances transitives le soient.

Pour chaque tâche affectée, inventoriez les éléments sensibles à l’architecture : binaires précompilés, extensions natives, outils téléchargés, scripts d’installation, dépendances de compilation et outils de test. Vérifiez le contenu des paquets et les choix d’installation ; ne déduisez pas leur compatibilité du seul fait qu’une étape install se termine. Lorsque les journaux le permettent, consignez l’architecture observée sur le Runner afin de rapprocher les résultats de l’environnement réellement utilisé.

Traitez ensuite séparément l’installation, la compilation et les tests. Une dépendance peut être disponible au téléchargement sans se compiler dans l’environnement cible ; une compilation réussie ne démontre pas que les tests chargent les bons composants ; et des tests réussis ne valident pas nécessairement l’archive signée destinée à la livraison. Si une cible Intel reste obligatoire, conservez une tâche explicitement adaptée à cette exigence, au lieu de compter sur le comportement implicite d’un label plus récent.

Les scripts qui sélectionnent une branche d’installation selon l’architecture méritent une lecture attentive. Certaines commandes peuvent choisir silencieusement une autre version de paquet ou une compilation à partir des sources, ce qui change les conditions d’exécution sans rendre le job immédiatement rouge. Comparez les versions installées et les journaux des outils avec la référence antérieure. Si le projet ne prend plus en charge une architecture donnée, documentez cette décision dans le workflow afin que les prochains changements de Runner ne la réintroduisent pas accidentellement.

Décider selon des conditions explicites

La sélection du Runner peut se faire avec ces critères de retour à une option maîtrisée :

• Si la documentation actuelle confirme le label, l’image et l’architecture nécessaires, et si la version de Xcode satisfait les exigences du projet, choisissez ce Runner pour un essai isolé.
• Si le label est disponible mais que les binaires, scripts ou dépendances ne sont pas validés pour son architecture, isolez ces jobs dans une matrice ou un Runner adapté ; ne migrez pas la publication en même temps.
• Si le projet exige une version de Xcode ou de macOS absente des images proposées, reportez le basculement de ce flux et utilisez une solution dont l’environnement peut être vérifié, jusqu’à ce qu’une option compatible soit confirmée.
• Si les builds passent mais que les tests Simulator, la signature ou l’archive échouent, ne déclarez pas la migration terminée : conservez le parcours de référence et corrigez ou séparez l’étape qui diverge.
• Si le nouveau Runner satisfait tous les critères de livraison sur le même commit, basculez progressivement les tâches concernées et gardez un chemin de retour documenté pendant l’observation des premières exécutions.

Cette décision évite de traiter macOS 15 ou macOS 26 comme une réponse universelle. Un label n’est qu’une demande d’environnement ; la conformité dépend de l’image effectivement disponible, des outils présents et des résultats obtenus avec le dépôt du projet.

Valider les résultats de bout en bout

Un test d’acceptation utile doit couvrir les tâches qui portent un risque réel pour la livraison, et produire des éléments comparables avec l’exécution précédente. Préparez un commit représentatif et gardez la configuration aussi proche que possible de celle de production ; autrement, une réussite peut simplement refléter un changement simultané dans les scripts ou les dépendances.

La liste de contrôle suivante sert de base avant le basculement :

• [ ] Le workflow ne référence plus un label retiré, y compris dans les matrices, les workflows réutilisés et les tâches de publication.
• [ ] Les journaux identifient le label, l’image, l’architecture et les versions d’outils effectivement utilisés.
• [ ] Une compilation propre termine sans réutiliser implicitement des produits construits dans l’ancien environnement.
• [ ] Les tests unitaires et d’intégration couvrent les composants principaux du projet.
• [ ] Les tests Simulator utilisent les destinations attendues par l’équipe, et les journaux confirment leur exécution réelle.
• [ ] Les dépendances privées sont accessibles avec les règles réseau et les identifiants du job de validation.
• [ ] La signature, l’archivage et la production des artefacts sont vérifiés si ces étapes font partie du flux de livraison.
• [ ] Les résultats, les journaux utiles et les informations d’artefacts sont conservés pour comparer les exécutions et diagnostiquer une régression.

Une compilation réussie constitue un signal, pas une preuve complète. Il faut examiner les tests représentatifs, les destinations utilisées et les artefacts réellement produits. Pour une livraison signée, contrôlez notamment que les certificats, profils et autorisations sont disponibles dans le contexte d’exécution prévu et que l’archive est exploitable. Les équipes qui ne publient pas depuis la CI peuvent exclure la signature de leur essai, à condition de ne pas présenter cette validation partielle comme une acceptation de la livraison complète.

L’accès réseau aux dépendances privées peut aussi changer le résultat sans lien direct avec Xcode. Vérifiez les règles d’accès, les secrets nécessaires et la manière dont les identifiants sont injectés ; ne recopiez pas des secrets dans des journaux ou des fichiers d’artefacts pour faciliter le diagnostic. Pour un Runner auto-hébergé, les équipes prennent également en charge les opérations et les exigences réseau associées : la documentation GitHub sur les Runner auto-hébergés décrit ces responsabilités.

Enfin, traitez le cache comme une optimisation, pas comme une preuve de reproductibilité. Pendant l’essai, comparez si nécessaire une exécution avec cache et une installation propre, puis vérifiez la clé et les chemins de cache lorsque les outils ou l’environnement changent. GitHub décrit les mécanismes de mise en cache des dépendances dans Actions ; leur présence ne dispense pas de vérifier les versions réellement installées.

Questions fréquentes sur la migration

Quel label utiliser après le retrait des Runner macOS 14 ?

Aucun label de remplacement ne convient à tous les dépôts. Consultez la liste actuelle des Runner hébergés et les images publiées, puis faites correspondre macOS, Xcode et architecture aux besoins du projet. Si plusieurs possibilités semblent acceptables, essayez-les sur un job isolé et comparez leurs résultats avant de changer les workflows de livraison.

Que contrôler avant de passer à macOS 15 ou macOS 26 ?

Vérifiez les exigences de Xcode et des SDK dans les sources Apple, puis confirmez que l’image sélectionnée contient réellement les outils attendus. Testez une compilation propre, les dépendances natives, les tests Simulator et les étapes de signature ou d’archivage utilisées par le projet. Une migration du système d’exploitation ne valide pas à elle seule la compatibilité de la chaîne d’outils.

Comment vérifier les tests Xcode et Simulator sur le nouveau Runner ?

Exécutez les tests sur les destinations Simulator utilisées par le projet et conservez les journaux indiquant les versions d’outils ainsi que les résultats. Faites l’essai sur le même commit que la référence, avec des conditions de dépendances comparables. Si le job produit une archive ou signe une application, vérifiez ces artefacts séparément au lieu de vous fier au seul état de réussite du build.

Comment maintenir un job de compilation Intel ?

Confirmez d’abord l’architecture proposée par le Runner dans les sources GitHub actuelles, puis inspectez les paquets binaires et scripts qui exigent Intel. Si cette cible reste nécessaire et qu’aucun environnement hébergé approprié n’est disponible, séparez le job plutôt que de supposer que le nouveau label se comportera comme l’ancien. Validez aussi installation, compilation et tests dans cet environnement.

Organiser le basculement et le retour arrière

Une fois les critères précédents satisfaits, faites passer d’abord les tâches de validation non publiantes sur le nouveau Runner. Comparez les journaux et les artefacts au même commit, puis déplacez les tests et les tâches de livraison selon le niveau de risque. Cette séparation rend plus facile l’identification d’une régression liée au système, à Xcode, à l’architecture ou à la configuration de signature.

Définissez à l’avance ce qui bloque la bascule : échec d’une compilation propre, test critique non exécuté, archive non conforme, dépendance privée inaccessible ou environnement différent de celui qui a été approuvé. Précisez aussi qui peut décider du retour arrière et quelle référence de workflow doit être restaurée. Sans ces règles, la décision de conserver ou de retirer le nouveau Runner se fait dans l’urgence, avec des résultats difficiles à comparer.

La mise à jour peut demander de revoir les caches, les outils installés à la volée et les scripts de sélection de Xcode. Consignez ces changements séparément de la modification du label afin d’éviter d’attribuer au Runner une différence causée par une autre évolution. Si les équipes constatent une attente ou un comportement réseau particulier, elles doivent s’appuyer sur leurs propres journaux et observations : les performances d’une ancienne image ne permettent pas de conclure sur la disponibilité ou les files d’attente d’une autre.

Un Runner hébergé peut convenir lorsque les images proposées répondent aux exigences et que l’équipe n’a pas besoin de contrôler durablement la machine. Un environnement macOS auto-hébergé offre davantage de maîtrise, mais apporte aussi des tâches d’administration, de sécurisation, de mise à jour et de reprise. Le bon choix dépend donc autant des contraintes d’exploitation que de la compatibilité de compilation.

Après le retrait, conserver les anciens labels dans une branche ou une configuration de secours ne rétablit pas leur disponibilité. Le retour arrière doit viser un environnement encore accessible et préalablement validé, ou reporter les tâches concernées jusqu’à ce qu’une solution compatible soit opérationnelle.

Choisir un environnement durable pour les validations Mac

Le remplacement ponctuel d’un Runner et le besoin d’un environnement Mac persistant sont deux décisions différentes. Si les jobs hébergés satisfont les exigences de version, d’architecture et d’accès réseau, ils peuvent rester le choix le plus simple. En revanche, les labels et images évoluent, l’équipe a moins de contrôle sur l’état durable d’une machine, et l’accès aux dépendances privées peut imposer des contraintes réseau spécifiques. Ces limites deviennent importantes lorsque la validation exige un environnement reproductible ou des essais interactifs hors des exécutions CI.

Un Mac distant peut servir de poste de vérification contrôlé lorsque le projet nécessite une chaîne Xcode stable, un accès direct à des outils macOS ou un diagnostic interactif. Cette option ne remplace pas automatiquement une CI hébergée : elle implique de gérer l’environnement et les secrets, et elle n’est pas adaptée à chaque équipe, notamment si une machine locale répond déjà au besoin ou si l’organisation exige un service CI entièrement géré. Les équipes qui étudient cette voie peuvent consulter les environnements Mac à distance de RUVCLOUD et comparer les conditions de leur projet avec les formules disponibles.

Pour une migration de Runner, l’approche la plus sûre reste de rejouer le même commit et les mêmes tâches de validation dans l’environnement cible avant d’autoriser la livraison. Si un Mac réel est nécessaire pour cette vérification, un environnement accessible à distance peut compléter les Runner hébergés sans prétendre résoudre à lui seul les contraintes de réseau, de sécurité ou d’exploitation. RUVCLOUD peut être envisagé pour disposer d’un Mac distant lors d’essais ciblés ; la pertinence dépend des exigences de l’équipe et des contrôles qu’elle doit conserver. Les détails de l’option de location sont présentés sur la page de commande de RUVCLOUD.