Après le premier arrêt macOS 14 : relever l’environnement avant de changer le label
Si un build iOS n’obtient pas de runner, vérifiez d’abord l’heure et le label. Le premier arrêt programmé allait du 5 octobre à 14:00 au 6 à 00:00 UTC, soit 23:00 à 09:00 KST.
GitHub a annoncé le 1er octobre le retrait de l’image au 2 novembre. Nous utilisons l’annonce et l’inventaire officiels vérifiés le 6 octobre 2026. La démarche est une proposition, pas une obligation GitHub.
Arrêt temporaire et retrait définitif
Les labels concernés sont macos-14, macos-14-large et macos-14-xlarge. La fin du premier arrêt n’annule pas le retrait. D’autres interruptions et des réductions possibles de capacité sont annoncées.
Le prochain intervalle va du 12 octobre à 14:00 au 13 à 00:00 UTC, soit 23:00 à 09:00 KST. Comparez journaux et état du service : ce calendrier n’explique pas tous les échecs.
Lire aussi l’architecture du remplacement
L’annonce propose des alternatives arm64 : macos-latest (macos-26), macos-15 et les variantes xlarge indiquées. L’inventaire les distingue de certains labels large ou intel x64.
En quittant macos-14-large, comparez les architectures. Dépendances natives, simulateurs, caches et empaquetage peuvent révéler des différences. La compatibilité propre au projet doit être testée.
Garder le même commit
Relevez label réel, OS, CPU, Xcode, SDK et fichier de verrouillage. Compilez et testez le même commit avec le même verrouillage sur le candidat. Ne mélangez pas migration et changements du code.
Au-delà du voyant vert, contrôlez archive, tests et étapes nécessaires de signature et d’export. Un essai ne reposant pas uniquement sur l’ancien cache précise la reproductibilité.
latest ne fige pas l’environnement
Le dépôt officiel explique que latest désigne l’OS stable le plus récent et que la migration peut être progressive. Une version explicite et les détails réels de l’image facilitent la comparaison sans garantir un support perpétuel.
latest peut convenir aux équipes qui vérifient continuellement. L’essentiel est de définir qui détecte le changement, quels éléments conserver et quand réparer ou revenir en arrière.
Conserver une comparaison et un responsable
Les interruptions rappellent que le cycle du runner fait partie de l’exploitation des releases. Nous ne revendiquons pas de fréquence communautaire mesurée. Planning officiel et preuves propres au workflow guident la décision.
Cherchez macOS 14 aussi dans les workflows réutilisables. Consignez essai candidat, responsable, prochaine revue, versions réelles et erreurs restantes. Profitez du délai avant le prochain arrêt pour vérifier.