Avant le retrait des runners macOS 14 de GitHub Actions, comment recenser tous les workflows hérités ? Liste 2026

Un workflow de publication fonctionne encore, mais personne ne sait s’il utilise un ancien runner macOS 14.

La réponse la plus sûre est de rapprocher l’inventaire des dépôts, des configurations réutilisées et des exécutions réelles, puis de valider la migration tâche par tâche. GitHub a annoncé le retrait des runners macOS 14 le 2 novembre 2026 ; une recherche limitée aux fichiers YAML de la branche par défaut ne prouve pas que tous les workflows concernés ont été trouvés. L’avis officiel de GitHub sur le retrait et les étiquettes concernées fait foi pour l’échéance et les consignes à jour.

Cet article s’adresse aux administrateurs d’organisations GitHub qui doivent repérer les anciennes étiquettes dans leurs dépôts.
Il est également destiné aux responsables CI qui doivent examiner les workflows réutilisables, les paramètres dynamiques et les exécutions.
Les responsables du développement et des publications y trouveront des critères pour documenter l’acceptation des migrations.

Dernière vérification : 8 octobre 2026, d’après l’avis de retrait de GitHub et la documentation GitHub Actions citée ci-dessous.

Le périmètre à inclure dans l’inventaire GitHub Actions

Commencez par définir ce que signifie « couvert » dans votre organisation. Il ne s’agit pas seulement de compter les fichiers inspectés : il faut pouvoir expliquer quels dépôts ont été inclus, quelles branches et quelles configurations ont été examinées, et pourquoi les éventuelles exceptions ne sont pas dans le champ.

Cette délimitation évite trois erreurs fréquentes. Premièrement, une recherche effectuée sur la seule branche par défaut ne révèle pas nécessairement une configuration présente sur une branche de maintenance. Deuxièmement, un dépôt inaccessible n’est pas un dépôt sans dépendance : son statut doit rester « non vérifié ». Enfin, les tâches déclenchées manuellement ou par un événement peu fréquent peuvent ne pas apparaître dans une fenêtre d’exécution récente.

Pour que votre inventaire soit révisable, notez la date de l’examen, les dépôts inclus, les restrictions d’accès et les décisions d’exclusion. Si un propriétaire de dépôt confirme qu’un workflow est obsolète, conservez cette confirmation et l’action de retrait prévue : ne transformez pas une supposition en preuve d’absence.

Comment vérifier que tous les dépôts sont couverts ?

La question utile n’est pas « la recherche a-t-elle renvoyé zéro résultat ? », mais « la recherche a-t-elle eu accès à tout le périmètre défini ? ». Rapprochez la liste des dépôts de l’organisation avec les résultats du balayage et signalez explicitement les dépôts archivés, transférés, inaccessibles ou en cours de fermeture.

Dans votre rapport, distinguez au minimum les états « analysé », « exclu avec justification » et « non vérifié ». Un état global « terminé » n’est défendable que si chaque dépôt du périmètre a l’un de ces statuts et si les dépôts non vérifiés sont traités comme un risque ouvert, plutôt que supposés conformes.

Comment repérer macOS-14 runner labels au-delà du YAML visible ?

L’avis de GitHub nomme trois étiquettes concernées : macos-14, macos-14-large et macos-14-xlarge. L’annonce officielle du retrait est la référence à consulter pour confirmer leur statut, les éventuelles périodes de brownout et les étiquettes de remplacement recommandées. Ne déduisez pas les performances, la disponibilité ou le comportement de file d’attente d’une étiquette de remplacement à partir de son seul nom.

La syntaxe officielle des workflows GitHub Actions décrit la configuration des jobs et de runs-on. Pour les valeurs qui varient selon un contexte ou une expression, examinez également la documentation sur les contextes et celle sur les expressions. Ces documents aident à comprendre la configuration ; ils ne remplacent pas la vérification du code réellement utilisé par votre organisation.

Pour chaque dépendance, associez le chemin du fichier à son origine et à son consommateur : dépôt de définition, nom du workflow, appelants connus et tâche concernée. Cette relation permet de savoir si la correction doit être apportée au modèle partagé, au paramètre transmis ou au workflow appelant. Modifier uniquement l’un de ces emplacements peut laisser les autres consommateurs sur l’ancienne valeur.

Comment examiner les runners des workflows réutilisables ?

Suivez la configuration du point d’appel jusqu’au job qui choisit le runner. Un workflow réutilisable peut recevoir un paramètre, puis affecter une valeur à runs-on ; le dépôt qui l’appelle ne mentionne donc pas nécessairement l’étiquette en clair. La documentation GitHub sur les workflows réutilisables décrit leur déclaration et leur appel : utilisez-la pour cartographier les relations, puis notez les chemins réellement examinés.

Si une matrice ou une expression détermine la valeur, consignez les valeurs possibles et leur provenance plutôt que le seul résultat visible dans le fichier. Pour les configurations fabriquées par un script, incluez le générateur et l’artefact produit, lorsque celui-ci est accessible. Un inventaire qui indique seulement « recherche effectuée » est difficile à auditer ; un inventaire qui relie source, consommateur et valeur du runner peut être reproduit par une autre personne.

Une absence d’occurrence littérale de macos-14 ne suffit pas à déclarer un workflow conforme si son étiquette est fournie par un paramètre, une matrice ou un fichier généré.

Comment rapprocher l’inventaire des exécutions réellement lancées ?

L’analyse statique répond à la question « que déclarent les fichiers consultés ? ». Les historiques d’exécution répondent à une autre question : « quels jobs ont effectivement démarré, et sur quel runner ? ». Pour établir une preuve, rapprochez ces deux vues. GitHub documente la consultation des exécutions de workflows via l’API REST ; vérifiez que votre accès permet d’examiner les dépôts et historiques pertinents, puis conservez la période et les filtres utilisés.

Repérez en particulier les workflows dont le déclenchement dépend d’une branche, d’un événement planifié ou d’une action manuelle. L’absence de défaillance récente ne prouve pas qu’ils ne dépendent pas d’un runner concerné : une tâche peut simplement ne pas avoir été exécutée pendant la période examinée. Enregistrez son nom, son événement de déclenchement, son étiquette observée, sa dernière exécution consultable et le responsable chargé de la faire fonctionner.

Quand l’historique disponible ne permet pas d’observer un scénario, faites-le apparaître comme une lacune de preuve. Si le workflow est nécessaire à une publication, prévoyez un déclenchement contrôlé avec son propriétaire avant de déclarer l’inventaire complet.

Quels critères rendent la migration acceptable pour chaque charge ?

Une migration n’est pas acceptée parce qu’une étiquette de remplacement figure dans la documentation. GitHub publie des recommandations et des informations sur les images ; c’est à votre équipe de vérifier que la configuration de destination convient à ses tâches. Consultez l’annonce de retrait et les informations officielles sur les images des runners hébergées avant de fixer la cible. Ne supposez pas que la disponibilité d’une image garantit la compatibilité avec vos dépendances, vos étapes de signature ou vos scripts.

Classez les tâches selon leur impact et attribuez un responsable. Une vérification de demande de fusion, une régression planifiée, une signature d’archive et une publication ne présentent pas le même risque opérationnel : un échec de test peut bloquer une fusion, tandis qu’un problème sur le chemin de signature ou de publication peut empêcher une livraison. Associez à chaque tâche son outil requis, sa configuration de signature, ses dépendances système et le scénario de réussite attendu.

Comment savoir si l’acceptation couvre bien tous les dépôts ?

Pour chaque migration, conservez le différentiel entre l’ancienne et la nouvelle configuration, le résultat du workflow et la liste des étapes vérifiées. Si une tâche échoue, notez si l’échec révèle une incompatibilité, une dépendance non documentée ou un problème sans rapport avec le changement de runner. Tant que l’explication et la décision ne sont pas consignées, l’échec reste un point ouvert ; ne le classez pas comme réussite par simple relance.

Utilisez cette liste comme outil de décision et joignez les preuves à votre suivi de changement :

• [ ] Le périmètre organisationnel est documenté ; chaque dépôt est analysé, exclu avec justification ou marqué comme non vérifié.
• [ ] Les trois étiquettes macos-14, macos-14-large et macos-14-xlarge ont été recherchées dans les emplacements de configuration pertinents.
• [ ] Les workflows réutilisables, leurs appelants, les paramètres, les matrices, les expressions et les configurations générées ont été examinés.
• [ ] Les résultats statiques ont été rapprochés des exécutions observées ; les tâches manuelles, planifiées ou rarement déclenchées sont identifiées.
• [ ] Chaque tâche possède une criticité, un responsable et une cible de migration vérifiée à partir de l’annonce GitHub en vigueur.
• [ ] Les tests couvrent les étapes nécessaires au scénario réel : construction, tests et, le cas échéant, signature ou publication.
• [ ] Les différences de configuration, résultats, exceptions approuvées et blocages non résolus sont conservés avec leur décisionnaire.
• [ ] La décision finale distingue les tâches migrées, les exceptions temporaires autorisées et les charges qui nécessitent un environnement Mac contrôlé.

Si l’annonce officielle mentionne des périodes de brownout, reportez-vous à son calendrier publié et vérifiez si vos workflows ont été exécutés pendant les fenêtres indiquées. En cas de modification de l’annonce ou des informations sur les images, réévaluez les tâches concernées : une preuve obtenue sur une cible antérieure ne valide pas une cible qui a changé.

Comment fermer les dépendances avant la date de retrait ?

Le retrait annoncé pour le 2 novembre 2026 doit être traité comme une échéance de gouvernance, pas comme une simple modification de chaîne dans les fichiers. Pour chaque dépendance non résolue, votre registre doit indiquer le dépôt, le workflow, la tâche métier, son propriétaire, la preuve manquante et la décision attendue. Cette structure vous permet de distinguer une migration acceptée d’une exception provisoire et d’un blocage de publication.

À l’approche de l’échéance, priorisez les travaux qui peuvent empêcher une livraison : signature, archivage et publication, puis les validations dont dépend la fusion. Pour chaque exception, faites consigner son approbateur, sa portée et la condition de fermeture. Si une tâche n’a pas pu être exécutée sur la cible retenue, écrivez « non validée » plutôt que de déduire son comportement à partir d’une autre tâche.

La décision d’hébergement dépend ensuite du besoin constaté. Les runners hébergés évitent à votre équipe de maintenir directement une machine, mais une migration d’image peut exiger de réexaminer les dépendances et le processus de validation. Un Mac contrôlé peut convenir lorsque le workflow requiert une configuration macOS particulière ou une maîtrise opérationnelle plus directe ; il implique en retour la gestion de l’accès, de l’entretien et de la continuité. Pour cadrer ce choix selon vos charges, consultez les cas d’usage Mac de KVMFLUX, puis examinez les modalités tarifaires de KVMFLUX si une capacité temporaire est à évaluer.

Si votre inventaire met en évidence une tâche qui doit être testée sur un Mac réel sans achat immédiat, une location peut servir d’environnement d’évaluation ou de capacité transitoire. KVMFLUX propose un accès à un Mac hébergé par VNC, SSH ou console web, avec des formules à la semaine, au mois ou au trimestre ; vérifiez que le mode d’accès, les règles de votre organisation et les exigences du workflow conviennent avant d’y transférer une charge. Pour une équipe ayant un besoin permanent, fortement standardisé ou dépendant d’interfaces physiques, comparez aussi la location à l’achat et à l’exploitation d’un Mac en propre. Dans tous les cas, gardez la décision de migration fondée sur les preuves de vos workflows, et non sur une promesse de compatibilité non testée.