Que faire si la version du Mac Runner autohébergé GitHub Actions est obsolète ? Guide de correction 2026

La première opération consiste à établir quel produit héberge les dépôts et quelle catégorie de règle s’applique au parc. L’annonce de GitHub ne se résume pas à « une version minimale pour tout faire » : elle distingue l’inscription ou la réinscription d’un Runner de sa capacité à continuer d’exécuter des tâches. L’état « en ligne » ne permet pas, à lui seul, de trancher cette seconde question.

Pour GitHub Enterprise Cloud, l’application de la règle annoncée a commencé le 29 septembre 2026. Un Runner dont la version est inférieure à 2.329.0 ne peut pas être inscrit ou réinscrit dans le périmètre concerné, selon l’annonce de GitHub sur le changement de calendrier et le seuil d’inscription. Ce seuil ne doit pas être transformé en exigence permanente pour toute exécution : les versions admises pour l’inscription et celles qui restent prises en charge pour exécuter des tâches sont deux contrôles différents.

Pour GitHub Enterprise Cloud avec résidence des données, l’application est entrée en vigueur le 31 juillet 2026, date également indiquée par GitHub dans son annonce officielle. GitHub Enterprise Server n’est pas concerné par cette annonce. Consignez le produit, l’organisation et le périmètre de résidence des données avant de définir les actions correctives ; ne déduisez pas l’applicabilité à partir du seul fait que les workflows utilisent GitHub Actions.

Un Runner GitHub Actions trop ancien cesse-t-il forcément de fonctionner immédiatement ?

Pas nécessairement à la même date ni pour la même raison. Une version peut être bloquée lors d’une nouvelle inscription ou d’une réinscription, tandis que la prise en charge de l’exécution dépend de la politique de retrait évolutive publiée par GitHub. Un Runner déjà enregistré et affiché comme actif peut donc ne pas satisfaire les conditions nécessaires à une tâche future. Vérifiez le statut de la version par l’API, puis confirmez le comportement avec une tâche réelle.

Un inventaire exploitable doit relier chaque machine à sa fonction dans la chaîne CI. Une simple liste d’hôtes ou une capture d’écran de l’état des runners ne suffit pas : elle ne révèle pas toujours la version installée, l’origine de l’installation, le périmètre d’inscription ni la manière dont la machine est recréée.

Pour chaque Mac, relevez :

• la version du logiciel Runner, le nom de la machine et son état de connexion ;
• le périmètre d’inscription — dépôt, organisation ou entreprise — et les étiquettes utilisées par les tâches ;
• le rôle du nœud : compilation, tests sur simulateur, signature, publication ou tâche auxiliaire ;
• la méthode de mise à jour : automatique, maintenance manuelle, script d’installation, image de base ou automatisation de déploiement ;
• les dépendances nécessaires aux tâches : version de Xcode, outils internes, certificats, accès réseau et mécanisme de stockage des secrets.

Cette distinction entre état déclaré et capacité opérationnelle est essentielle. L’interface peut montrer un Runner disponible alors que son environnement de construction est incomplet, que ses outils ne correspondent plus au projet ou que la tâche attend une étiquette absente. À l’inverse, un nœud occupé pendant l’inventaire n’est pas forcément défaillant : son statut doit être interprété avec son activité et son rôle.

Utilisez la documentation GitHub sur la gestion des runners autohébergés sur Mac pour vérifier la méthode de gestion adaptée à votre configuration. Exportez ensuite les informations d’inventaire dans une source suivie par l’équipe, avec une date de collecte et un responsable. N’enregistrez pas les secrets dans ce fichier : il doit permettre d’identifier le nœud et ses dépendances sans exposer les éléments de signature.

La stratégie dépend d’abord de la façon dont les machines sont maintenues. Le tableau ci-dessous sert à choisir le contrôle prioritaire, et non à conclure qu’un mode est toujours préférable.

La mise à jour automatique n’exonère pas l’équipe de vérifier le résultat. Si le nœud ne peut pas accéder au service requis, ou si la configuration bloque les mises à jour, une politique supposée automatique peut laisser s’accumuler des versions anciennes. La documentation officielle des runners autohébergés décrit les principes de mise à jour et les situations où l’équipe doit intervenir.

2.329.0 est-elle la version minimale commune à l’inscription et à l’exécution des workflows ?

Non. Le seuil 2.329.0 de l’annonce concerne l’inscription ou la réinscription dans le périmètre indiqué ; il ne constitue pas une garantie que cette version restera durablement acceptée pour l’exécution. Pour savoir si une version installée peut encore prendre des tâches, consultez le statut de retrait courant dans l’API officielle, puis rapprochez-le du produit et du périmètre concernés.

Ne fondez pas une décision de maintenance sur le seul numéro de version ou sur un ancien ticket. Les conditions d’exécution évoluent ; un seuil valable lors d’une inscription ne répond pas nécessairement à la question « cette version peut-elle encore exécuter un workflow ? ». L’API REST GitHub consacrée au retrait des versions de runners est la référence pour vérifier les dates et les états applicables.

Procédez de façon traçable :

• identifiez les versions présentes dans l’inventaire, y compris celles utilisées par les scripts et images de remplacement ;
• interrogez l’API documentée et conservez la réponse avec la date de vérification ;
• associez le statut retourné à chaque version installée, en distinguant inscription et exécution ;
• signalez séparément les versions déjà retirées, celles dont la date de fin approche et celles dont le statut est encore conforme ;
• déclenchez une vérification à nouveau après une annonce de GitHub ou une modification du comportement de l’API.

L’automatisation doit rendre les exceptions visibles : version inconnue, donnée manquante, réponse impossible à rapprocher de l’inventaire ou vérification échouée. Ne classez pas silencieusement ces cas comme conformes. Une alerte n’a de valeur que si elle indique le nœud ou le modèle concerné, le statut trouvé, la source vérifiée et le responsable chargé de l’action.

Comment trouver la date de retrait d’une version précise ?

Relevez d’abord la version exacte sur le Mac concerné, puis recherchez son statut au moyen de l’API de retrait documentée par GitHub. Reliez la réponse à l’actif correspondant et consignez la date de consultation : un relevé conservé sans date devient vite ambigu lorsque les règles changent. Évitez d’extrapoler la date d’une version voisine à celle du Runner installé.

L’objectif n’est pas seulement d’installer une version plus récente : il faut éviter qu’une mise à jour simultanée rende indisponible la capacité de compilation, ou qu’un remplacement remette en circulation un ancien Runner. Déployez une modification à la fois sur un groupe maîtrisable et préservez un chemin de retour défini avant l’intervention.

Préparer la source et le retour arrière

Avant le déploiement, identifiez si le Runner est mis à jour sur place ou recréé depuis un modèle. Pour les nœuds recréés, modifiez d’abord les scripts d’installation, images de base, modèles de cache et définitions de conteneurs concernés. Sinon, la mise à niveau manuelle des hôtes existants sera annulée au prochain remplacement.

Documentez la version cible, la source utilisée, les dépendances de l’environnement et la procédure de restauration. Le retour arrière ne doit pas consister à remettre en production une version que GitHub ne prend plus en charge : prévoyez plutôt une restauration de la configuration ou des outils, tout en conservant une version Runner admissible. Si la mise à jour échoue, suspendez le déploiement suivant et consignez l’erreur avant de relancer l’opération.

Déployer progressivement

Commencez par un nœud non critique dont les étiquettes et les outils représentent suffisamment bien une tâche de production. Vérifiez l’installation, l’enregistrement, la réception d’une tâche et la fin correcte du processus. Si ces contrôles passent, poursuivez par petits groupes ; conservez en parallèle une capacité de compilation suffisante pour les équipes et ne mettez pas simultanément tous les nœuds d’un même rôle en maintenance.

Pour les installations manuelles, la documentation GitHub sur la surveillance et le dépannage des runners aide à examiner les journaux et les états de fonctionnement. Une mise à jour qui semble terminée sur le Mac mais ne donne lieu à aucune tâche réussie n’est pas une mise à niveau validée.

Comment entretenir un Runner après désactivation de la mise à jour automatique ?

Désignez un propriétaire opérationnel, planifiez des vérifications de version et d’état de retrait, puis définissez une procédure de mise à jour manuelle avec un essai préalable. Ajoutez un contrôle aux scripts ou images qui recréent les nœuds, et conservez les journaux d’installation ainsi que le résultat des tests. Sans responsable ni alerte, une désactivation ponctuelle se transforme facilement en version oubliée.

Une vérification de version établit l’admissibilité du Runner ; elle ne prouve pas que le service rendu par le nœud reste utilisable. L’acceptation doit donc emprunter le parcours réel d’iOS CI/CD, à partir d’un workflow représentatif des étiquettes, outils et accès utilisés en production.

Cochez les contrôles au fur et à mesure :

• [ ] Le Runner s’enregistre dans le bon périmètre, apparaît dans l’état attendu et correspond aux étiquettes visées.
• [ ] Une tâche de test est effectivement attribuée à ce Mac ; la seule présence en ligne ne vaut pas preuve de prise en charge.
• [ ] L’environnement macOS, Xcode et les dépendances nécessaires sont détectés par le workflow.
• [ ] La compilation et les tests représentatifs se terminent avec un résultat exploitable, et leurs journaux sont consultables.
• [ ] Si le nœud signe ou publie un artefact, la tâche complète est vérifiée avec les droits et secrets autorisés, sans exposer ces derniers dans les journaux.
• [ ] Le processus de remplacement ou de redémarrage ne réintroduit pas une version ancienne et le nœud peut reprendre son rôle après maintenance.

Ces vérifications révèlent les défauts qui échappent à un simple contrôle de connexion : outils manquants, accès réseau modifié, secret indisponible ou configuration de signature interrompue. En cas d’échec, isolez la cause avant d’étendre le déploiement. La documentation de surveillance et de dépannage mentionnée plus haut peut guider l’analyse des journaux et des problèmes de connexion ; conservez le résultat du workflow comme preuve d’acceptation.

Après la remise en service, faites du contrôle des versions une tâche récurrente plutôt qu’une intervention déclenchée uniquement par une panne. Reliez l’inventaire à une interrogation de l’API officielle, puis produisez une alerte quand une version est retirée, approche de son échéance ou ne peut pas être vérifiée.

La procédure d’exploitation doit préciser qui traite une mise à jour automatique en échec, qui intervient si le service de mise à jour est inaccessible et à partir de quel constat un déploiement est suspendu. Pour une file de tâches qui reste en attente, vérifiez également le périmètre d’inscription, les étiquettes, l’état du Runner et le comportement du workflow : une attente n’indique pas à elle seule un problème de version.

Conservez un dossier de changement avec l’inventaire avant et après intervention, la réponse de l’API, les journaux utiles et le résultat des workflows d’acceptation. Réexaminez la règle à la suite d’une nouvelle annonce GitHub, d’un changement des conditions d’exécution ou d’une modification de l’API. Cette trace permet de distinguer une panne logicielle d’un défaut de configuration ou d’une règle devenue applicable.

Pour un parc important, répartissez clairement la responsabilité entre l’équipe qui maintient les Mac et celle qui possède les workflows. La première peut garantir la version du Runner et l’état du système ; la seconde doit confirmer les outils, les autorisations et le résultat métier de la compilation. Sans cette séparation, un nœud peut être déclaré « à jour » alors que sa chaîne de livraison demeure inutilisable.

Si les mises à niveau créent un manque temporaire de capacité, comparez d’abord le maintien des Mac détenus en propre — investissement immobilisé, entretien et charge liée au remplacement — avec une capacité distante mobilisable pendant la transition. Une machine locale reste pertinente lorsque l’équipe a besoin d’interfaces physiques ou d’une charge soutenue et prévisible ; une solution distante ne dispense ni de gouverner les versions ni d’autoriser correctement les tâches. Pour un besoin ponctuel de capacité macOS, consultez les environnements Mac proposés par NUKCLOUD et évaluez leur intégration après validation de la chaîne CI, plutôt que de les considérer comme un correctif automatique au défaut de Runner. Pour les questions d’accès et de prise en main, la page d’aide NUKCLOUD permet de vérifier les informations disponibles avant de retenir cette option.