Avant le retrait de GitHub Actions macOS-14, comment migrer l’iOS CI ? 2026

GitHub annonce le retrait des étiquettes macOS-14, macOS-14-large et macOS-14-xlarge le 2 novembre 2026. L’annonce indique également des étiquettes de remplacement, mais cette recommandation ne prouve pas qu’un environnement donné convient à chaque projet iOS. Les informations sur la date et les étiquettes concernées figurent dans l’annonce de retrait de GitHub.

Cette échéance est courte pour une chaîne qui doit produire des archives signées, respecter des contrôles de publication et préserver une voie de reprise. Notre conseil immédiat : cette semaine, extraire une exécution réelle de publication, noter son environnement effectif et choisir un flux à tester hors production. Ne modifiez pas encore toutes les définitions de tâches en même temps.

Le périmètre de ce guide est volontairement limité : il traite de la migration des flux iOS déjà en service. Il ne remplace ni l’inventaire organisationnel des anciennes étiquettes ni un guide de dépannage lors d’un incident de Brownout. Le besoin est différent : établir une référence comparable, prouver la compatibilité, puis décider quels travaux peuvent être autorisés en production.

Quelles tâches de workflow modifier en premier ? Commencez par celles qui utilisent explicitement une étiquette macOS-14 et qui produisent un artefact destiné à une étape ultérieure : compilation, tests, archivage ou publication. Repérez ensuite les tâches qui partagent un même travail de signature ou un même secret de publication. Ne vous fiez pas uniquement au texte du fichier YAML : le journal d’exécution doit confirmer le Runner réellement sélectionné. La documentation GitHub sur le choix du Runner d’une tâche explique les étiquettes et l’assignation des tâches.

Ce tableau sert à organiser l’évaluation, pas à déclarer une compatibilité générale. Les étiquettes ne suffisent pas à déduire la version de Xcode, le contenu exact de l’image ou les résultats d’exécution. Consultez les images officielles des Runner GitHub et les journaux de vos propres tâches. Pour chaque candidat, comparez la version système, l’architecture rapportée et l’outil réellement invoqué. L’index des exigences système de Xcode permet ensuite de vérifier si la version de Xcode requise correspond à l’environnement envisagé.

Une migration est difficile à évaluer si l’ancienne exécution n’a pas été consignée. Prenez un flux de publication réel et documentez ses entrées et ses résultats, sans exposer les secrets dans les journaux ou dans un dossier de comparaison.

Relevez notamment l’étiquette demandée, l’étiquette du Runner attribué et les informations d’environnement visibles dans les journaux. Notez également la sélection effective de Xcode : une commande qui choisit un outil par chemin ou une variable d’environnement peut rendre trompeuse la seule lecture de l’étiquette du Runner. Conservez la résolution des dépendances, les commandes de compilation et de test, les réglages d’archivage, ainsi que les étapes d’exportation et d’envoi de l’application.

Pour la comparaison, définissez des preuves que l’équipe peut examiner sans interprétation ambiguë : état de la tâche, journaux, artefact produit, identité de signature attendue, profil utilisé et résultat des étapes de publication. Un simple indicateur « vert » ne prouve pas que le flux a utilisé le bon Xcode, généré la bonne archive ou signé avec l’identité prévue.

Établissez aussi la liste des tâches qui ne peuvent pas être interrompues sans décision de publication. Distinguez la validation de code, la compilation destinée aux tests, la création d’une archive distribuable et l’envoi vers une destination de publication. Ces opérations ne partagent pas nécessairement les mêmes autorisations ni le même niveau de risque. Cette séparation permet de migrer d’abord un travail réversible, sans accorder à un essai exploratoire des droits de production.

Un Runner peut démarrer correctement sans que la chaîne de publication soit validée. Nous considérons la migration comme acceptée seulement lorsque les preuves de compilation, d’archivage et de signature sont comparables à la référence et que les secrets n’ont pas été élargis pour faciliter l’essai.

La cible se choisit à partir des exigences du projet, et non parce qu’une étiquette semble plus récente. Commencez par recenser les versions minimales et maximales acceptables pour macOS et Xcode, les dépendances utilisées, les simulateurs requis et les exigences d’architecture. Si une dépendance, un script de construction ou un outil interne repose sur un comportement spécifique, vérifiez-le dans le projet lui-même : le nom du Runner n’en apporte pas la preuve.

La documentation du dépôt des images Runner aide à examiner les versions et les contenus annoncés pour les images. Les informations évoluent ; relevez donc la version observée au moment de l’essai plutôt que de traiter une capture ancienne comme un contrat. Confrontez ces observations aux exigences publiées par Apple pour Xcode, puis aux journaux de votre flux.

Comment vérifier Xcode lors d’un passage de macOS-14 à macOS-15 ou macOS-26 ? Lancez le flux isolé avec la cible candidate et enregistrez à la fois la version de macOS détectée et le chemin ou la version de Xcode réellement employé. Exécutez les commandes du projet sans les simplifier pour l’essai. Si la compilation appelle un Xcode différent de celui attendu, ou si un simulateur ou une dépendance manque, arrêtez l’évaluation et corrigez l’environnement avant de juger le résultat.

La migration ne se résume pas à « l’application compile ». Un changement d’image peut modifier la résolution d’une dépendance, le comportement d’un script ou la disponibilité d’un outil. Une compilation réussie sur un candidat ne valide donc pas automatiquement le test, l’archivage, l’exportation et la signature. Consignez les écarts observés et classez-les : incompatibilité réelle, configuration implicite dans le flux, ou différence d’environnement qui peut être fixée.

Créez une branche de validation ou un workflow séparé, puis reproduisez le chemin réel de publication avec les mêmes commandes et la même configuration non sensible. Le but n’est pas de produire une imitation simplifiée : il faut vérifier les étapes qui peuvent réellement bloquer une livraison. En revanche, l’essai ne doit pas accéder aux identifiants de publication de production si cette autorisation n’est pas nécessaire.

Examinez les différences étape par étape. Les dépendances se résolvent-elles comme prévu ? La compilation utilise-t-elle l’outil attendu ? Les tests pertinents se terminent-ils ? Le processus crée-t-il et exporte-t-il une archive ? La signature est-elle contrôlée avec les informations prévues ? Apple décrit la création de code signé pour la distribution dans sa documentation sur l’archivage et l’exportation. Servez-vous-en pour vérifier les étapes d’exportation, sans supposer que la documentation remplace les règles propres à votre application.

Comment valider l’archive, la signature et l’envoi avant publication ? Reproduisez le processus avec des autorisations limitées, puis vérifiez le résultat de chaque étape dans les journaux et sur l’artefact. Lorsque le test d’envoi ne peut pas être réalisé sans une autorisation de production, faites valider séparément les contrôles de signature et d’accès, puis consignez clairement ce qui reste à prouver. Ne déclarez pas la chaîne complète acceptée si une étape décisive n’a pas été exécutée.

Définissez à l’avance ce qui déclenche un arrêt : différence inattendue de Xcode, échec de tests requis, archive non conforme, signature différente ou accès réseau indisponible. Décrivez ensuite une correction, un responsable et la preuve nécessaire pour reprendre l’essai. Les protections des environnements GitHub peuvent limiter les déploiements à des branches ou à des validations approuvées ; consultez la documentation sur les environnements et leurs règles de protection. Protégez également les secrets conformément aux recommandations de sécurité des workflows GitHub Actions.

Ne remplacez pas toutes les étiquettes dans une modification générale, puis ne découvrez pas les écarts au moment d’une publication. Commencez par un flux qui a réussi l’essai isolé et dont le retour arrière est compris. Après validation, élargissez la migration aux autres tâches en tenant compte de leurs dépendances, de leur usage des secrets et de leur criticité pour les publications.

Pour chaque lot, conservez une définition claire de la cible et vérifiez les journaux de la première exécution en production. Les tâches concurrentes méritent une attention particulière : deux publications ou deux travaux qui modifient une ressource partagée peuvent se gêner. Définissez une politique adaptée à vos flux et examinez les groupes de concurrence de GitHub Actions plutôt que d’ajouter une sérialisation sans comprendre ses effets.

Que faire si la migration échoue ? Arrêtez l’élargissement du changement, préservez les journaux et identifiez l’étape qui diverge. Si l’ancienne étiquette est encore disponible pendant la période précédant son retrait, elle peut aider à comparer les résultats ; elle ne constitue pas un plan de repli après la date annoncée. La reprise doit revenir à un Runner de remplacement déjà validé, ou à une autre voie testée, et non à une dépendance permanente envers macOS-14.

Après chaque changement, contrôlez que l’étiquette configurée correspond au Runner réellement affecté. Une définition modifiée ne garantit pas qu’un travail a emprunté la voie souhaitée : des contraintes de routage ou la disponibilité des hôtes peuvent conduire à un environnement différent. Gardez une trace de la cible choisie, de l’exécution observée et de la décision de poursuivre ou d’arrêter.

Certaines tâches peuvent exiger un accès réseau particulier, une gestion spécifique de la signature ou une continuité que la cible de remplacement n’offre pas. Avant de rechercher un autre hôte, écrivez précisément l’exigence qui bloque : version nécessaire, outil manquant, accès à une ressource, mode d’authentification, besoin de présence continue ou contrainte de droits. « Le nouveau Runner ne fonctionne pas » n’est pas une spécification exploitable.

Pour évaluer un Mac distant ou auto-hébergé, reprenez les mêmes preuves que pour l’essai isolé : environnement constaté, version de Xcode choisie, dépendances, artefact, signature, accès réseau et procédure de reprise. Vérifiez aussi comment sont délivrés les identifiants, qui peut administrer la machine et comment les tâches sont isolées. Ces conditions doivent être confirmées dans les modalités réellement proposées ; nous ne déduisons ni configuration, ni prix, ni région, ni délai de livraison d’une simple page de présentation.

Les règles de sécurité restent déterminantes. Un Mac de secours n’est pas une solution acceptable si les secrets de publication y sont plus largement accessibles ou si les tâches de test peuvent déclencher un envoi non autorisé. Définissez les permissions et les protections avant d’y transférer des flux sensibles. Si la continuité dépend de plusieurs tâches concurrentes, vérifiez aussi la capacité réelle par des exécutions représentatives au lieu de l’estimer à partir du seul nom du matériel.

Avant de considérer la migration terminée, nous utilisons cette liste de contrôle. Chaque élément doit correspondre à une preuve consultable ou à une décision documentée.

• [ ] L’annonce de retrait et l’état courant des étiquettes ont été revérifiés dans les sources officielles.
• [ ] Le journal confirme l’étiquette attribuée, la version de macOS et le Xcode réellement utilisés.
• [ ] Le flux de référence couvre les dépendances, la compilation, les tests et les étapes de publication pertinentes.
• [ ] L’archive et la signature ont été contrôlées selon les exigences propres au projet.
• [ ] L’essai a utilisé des autorisations adaptées et n’a pas exposé les identifiants de production sans nécessité.
• [ ] La première tâche migrée a un critère d’arrêt et une voie de reprise déjà testée.
• [ ] Les tâches restantes sont classées par compatibilité et criticité, avec un responsable de suivi.
• [ ] Toute tâche qui échoue sur les Runner candidats dispose d’exigences explicites pour évaluer un Mac de secours.

La décision finale ne doit pas être « l’étiquette a changé », mais « les preuves de publication sont acceptées, les autorisations sont maîtrisées et la reprise est réalisable ». Lorsque l’image candidate échoue sur un besoin précis, conservez ce besoin comme critère de sélection d’une autre voie. Ne compensez pas une incompatibilité inconnue par une mise en production générale.

Pour comparer une capacité GitHub Actions gérée à un Mac dédié ou distant, mettez en regard les mêmes éléments : compatibilité des outils, contrôle des accès, disponibilité attendue, effort d’exploitation et coût total de possession. Un Runner géré évite à l’équipe d’administrer un hôte, mais laisse moins de contrôle sur certains détails de l’environnement ; un Mac dédié offre un périmètre plus maîtrisable, au prix de responsabilités opérationnelles et de vérifications supplémentaires. Pour un besoin temporaire ou une tâche de publication qui ne passe pas sur les Runner candidats, consultez la présentation de MESHLAUNCH et vérifiez que les conditions proposées correspondent à vos exigences avant de déplacer un flux. Vous pouvez également examiner les options Mac mini présentées par MESHLAUNCH, sans en déduire à l’avance qu’elles répondent à votre besoin de signature, de réseau ou de continuité.

Si vos tâches sont stables, récurrentes et exigent un contrôle matériel durable, l’achat et l’exploitation d’un Mac peuvent rester plus adaptés. Si le besoin porte sur une validation ou une capacité temporaire, une location peut éviter d’engager un achat avant d’avoir mesuré la charge réelle. Dans les deux cas, ne basculez qu’après avoir vérifié l’environnement, les permissions et le retour arrière avec une véritable tâche de publication.