GitHub Actions Runner expiré : mise à niveau Mac 2026

Le 12 juin 2026, GitHub a publié un calendrier officiel d’application d’une version minimale pour les Runner auto-hébergés. Consultez l’annonce officielle sur les versions minimales des Runner avant toute intervention : un Runner peut donc rester affiché « en ligne » tout en cessant d’accepter certains travaux.

Symptôme → solution la plus rapide

Le Runner est en ligne, mais les tâches restent en attente ou ne sont plus attribuées → vérifiez immédiatement la portée de l’application, la version indiquée dans votre compte et les journaux du Runner. Si la mise à niveau directe met en danger votre seule Mac, créez d’abord un nœud distant isolé, copiez la chaîne minimale de compilation, puis faites basculer les étiquettes après validation.

Qui doit lire ce guide ?
Les développeurs individuels qui n’ont qu’un Mac Runner actif et ne peuvent pas perdre leur capacité de compilation pendant la maintenance.
Les petites équipes, les plateformes DevOps et les responsables de publication qui partagent des signatures, des caches, Xcode ou un parc de nœuds soumis à des règles réseau particulières.

Dernière mise à jour : 26 août 2026. Les règles, dates d’exécution et méthodes de diagnostic ont été vérifiées dans les annonces et la documentation officielles de GitHub ainsi que dans le guide de téléchargement affiché par le compte concerné.

Le statut « en ligne » ne suffit pas pour juger la version du Runner

Une version expirée du GitHub Actions Runner ne provoque pas nécessairement une panne franche du Mac. Le service peut démarrer, répondre à la supervision et conserver ses étiquettes, alors que GitHub applique déjà une exigence minimale pour l’attribution de tâches. C’est la différence essentielle entre un problème de workflow et un problème d’éligibilité du nœud.

Ne concluez donc pas à partir de l’icône « en ligne ». Vérifiez plutôt les éléments suivants :

• le type de compte concerné : dépôt, organisation ou entreprise ;
• le groupe de Runner auquel le nœud appartient ;
• les étiquettes réellement utilisées par les workflows ;
• la version affichée dans l’interface d’administration ou dans les journaux ;
• l’état de la mise à jour automatique ;
• la note ou le message d’exécution associé à la restriction ;
• la date et la portée indiquées dans l’annonce GitHub applicable à votre compte.

GitHub distingue plusieurs niveaux de gestion des Runner et documente les mécanismes d’administration dans sa documentation officielle sur les Runner auto-hébergés. La vérification doit être faite dans le compte qui exécute effectivement le workflow : une règle visible au niveau d’une organisation ne prouve pas que tous les dépôts ou groupes sont touchés de la même manière.

Comment vérifier la version actuelle d’un Runner auto-hébergé ?

Ouvrez les paramètres du dépôt, de l’organisation ou de l’entreprise selon le niveau d’enregistrement, puis consultez la liste des Runner et le détail du nœud. Comparez cette information avec le guide de téléchargement visible dans votre compte et avec les versions publiées du dépôt officiel actions/runner. Ne recopiez pas un numéro trouvé dans un ancien résultat de recherche : la version disponible et la version minimale peuvent évoluer.

Sur le Mac, examinez aussi le journal du service et l’état du processus. Un contrôle utile consiste à conserver, avant intervention, une copie textuelle de la version, du nom du Runner, du groupe et des étiquettes. Vous pourrez alors comparer l’état avant et après la maintenance au lieu de vous fier à une simple reconnexion.

Choisir l’action selon la taille et le rôle du nœud

Le bon choix dépend moins du modèle de Mac que de la perte acceptable pendant l’opération. Un nœud unique destiné à des tests peut être traité différemment d’un nœud qui signe et publie une application. Le tableau suivant sert de filtre initial avant de modifier le service.

Score de risque pour décider de la bascule

Attribuez un point à chaque réponse positive :

• le nœud est le seul à porter une étiquette de production ;
• il utilise un trousseau de clés ou un certificat non encore restauré ailleurs ;
• l’accès sortant passe par un proxy ou une liste blanche ;
• l’automatisation de mise à jour est désactivée ;
• le workflow produit un artefact destiné à une publication ;
• aucun retour arrière documenté n’a été exécuté.

Avec zéro ou un point, une mise à niveau directe peut être envisageable après sauvegarde. Avec deux ou trois points, prévoyez un nœud isolé et une migration progressive. Au-delà, traitez le Mac comme une dépendance critique : créez un secours, faites valider la chaîne complète et conservez l’ancien nœud hors service jusqu’à la fin de la période d’observation définie par votre équipe.

Ces seuils sont un outil de décision interne, pas une règle GitHub. Ils évitent surtout de confondre une opération technique simple avec un changement de chaîne de publication.

Le développeur seul doit préserver une capacité de construction minimale

Si vous êtes la seule personne à administrer un Mac Runner, commencez par documenter ce qui permet de le reconstruire. Ne copiez pas seulement le répertoire du Runner. Notez les étiquettes, le groupe, le compte de service, le chemin de travail, les versions d’outils, les variables non secrètes, le mode de démarrage et les dépendances de signature.

Les éléments sensibles doivent être traités selon votre politique de secrets. Le certificat, la clé privée, le trousseau et le profil de provisioning ne doivent pas être déposés dans un dépôt ou dans un fichier de diagnostic. En revanche, vous devez savoir où ils sont restaurés, quel compte peut les déverrouiller et comment vérifier leur présence sans exposer leur contenu.

Avant de lancer l’installation, préparez au moins un plan de continuité :

1. désactivez temporairement l’attribution de nouvelles tâches au nœud si votre procédure le permet ;
2. conservez la configuration des étiquettes et du groupe ;
3. copiez les journaux récents et l’état du service ;
4. préparez un Mac de secours, local ou distant, avec un accès administrateur ;
5. installez uniquement la chaîne minimale nécessaire au workflow prioritaire ;
6. enregistrez ce nœud avec une étiquette distincte ;
7. exécutez un vrai workflow de compilation avant toute bascule.

Un nœud Mac distant pour la compilation peut servir de zone isolée lorsque votre Mac de production ne peut pas être arrêté immédiatement. Il ne remplace pas la validation de vos certificats ni de votre projet, mais il vous donne une cible séparée pour vérifier l’enregistrement et le routage sans écraser le nœud existant.

L’acceptation minimale doit couvrir l’enregistrement, la sélection par étiquette, le redémarrage du Mac, la reconnexion du service et un projet réel. Un script qui retourne seulement un code de succès ne valide pas Xcode, le trousseau ou l’archivage.

L’équipe partagée doit migrer les dépendances avant le Runner

Dans une petite équipe, le risque principal n’est pas toujours le programme Runner lui-même. Il se trouve souvent dans les différences invisibles entre la machine historique et le nœud de remplacement : cache de dépendances, version de Xcode, outil de signature, plugin audio, bibliothèque graphique ou fichier local utilisé par une tâche de design.

Commencez par classer les workflows :

• tests unitaires sans signature ;
• compilation avec dépendances mises en cache ;
• export signé ;
• archivage ;
• publication ou distribution ;
• tâches audio, vidéo ou design nécessitant des outils installés localement.

Les travaux à faible risque passent en premier sur le nœud de grisage. Les tâches de signature et de publication restent sur l’ancien Mac tant que vous n’avez pas comparé les journaux, l’artefact et la chaîne de certificats. Pour les équipes qui produisent aussi des applications créatives, vérifiez les codecs, les polices, les extensions et les accès aux volumes locaux : une compilation réussie ne prouve pas qu’un rendu Final Cut Pro ou qu’une étape audio pourra s’exécuter.

La migration se fait ensuite en trois mouvements : un nœud isolé, quelques dépôts peu critiques, puis les workflows de publication. Conservez pour chaque tâche son identifiant, son journal, le résultat de la compilation et l’empreinte de l’artefact lorsque votre chaîne le prévoit. La documentation GitHub sur la surveillance et le diagnostic des Runner fournit le cadre pour examiner les tâches attribuées, les erreurs de service et les symptômes de connectivité.

Les nœuds à réseau restreint exigent une chaîne de mise à jour vérifiable

Que faire lorsque la mise à jour automatique du Runner est désactivée ?

Ne lancez pas immédiatement un téléchargement manuel sur le Mac de production. Vérifiez d’abord si le nœud peut joindre les services nécessaires via le proxy, si le compte de service peut écrire dans le répertoire d’installation et si la politique de sécurité autorise le remplacement des fichiers. Comparez ensuite le paquet avec le guide de téléchargement affiché dans votre compte et avec la publication correspondante du dépôt officiel.

Une procédure manuelle fiable comporte les étapes suivantes :

1. enregistrer la version actuelle et l’état du service ;
2. tester la résolution DNS, la connexion sortante et le proxy utilisé ;
3. télécharger le paquet depuis la source approuvée ;
4. conserver son empreinte ou son mécanisme de vérification prévu par votre chaîne ;
5. arrêter le service avec le compte autorisé ;
6. installer la nouvelle version sans supprimer les informations de rattachement nécessaires ;
7. redémarrer le service et vérifier les journaux ;
8. exécuter un workflow réel, puis archiver les preuves.

Les commandes exactes dépendent du mode d’installation et du service macOS utilisé. Employez vos propres valeurs à la place de <ORGANISATION>, <DEPOT>, <GROUPE>, <CHEMIN_DU_RUNNER> et <COMPTE_SERVICE>. Évitez de publier un jeton ou une clé dans l’historique du terminal.

Pourquoi un ancien Runner peut-il rester en ligne sans prendre de tâche ?

Les causes les plus probables sont une version minimale désormais exigée, une étiquette qui ne correspond plus au workflow, un groupe auquel le dépôt n’a pas accès, une session de service dégradée ou une connectivité sortante partielle. Un statut en ligne montre que le processus communique encore ; il ne garantit ni l’éligibilité à toutes les tâches ni la disponibilité des outils locaux. Pour les inventaires automatisés, utilisez les points de contrôle décrits dans la documentation REST des Runner auto-hébergés, puis confrontez-les aux journaux du nœud.

Ne désactivez pas la validation TLS comme réparation habituelle. Cette exception affaiblit la vérification du canal et peut masquer un proxy mal configuré ou un certificat interne expiré. Si une dérogation temporaire est imposée par une procédure de crise, consignez son propriétaire, sa durée, son périmètre et la méthode de restauration avant de l’appliquer.

Le parc d’entreprise doit être traité par lots et par cycle de vie

Pour un parc important, construisez un inventaire exportable contenant le groupe, l’organisation, le dépôt autorisé, l’architecture, les étiquettes, la version, le mode de mise à jour, le propriétaire opérationnel et le rôle du nœud. Séparez les Mac de test, les nœuds permanents, les nœuds éphémères et les nœuds qui signent ou publient.

Les stratégies ne doivent pas être uniformes :

• un nœud éphémère peut être reconstruit à partir d’une image validée plutôt que mis à niveau sur place ;
• un nœud permanent doit conserver sa configuration et son historique de journaux ;
• un groupe à mise à l’échelle automatique doit intégrer la nouvelle image avant de retirer l’ancienne ;
• un nœud de publication doit disposer d’un chemin de bascule testé et d’une conservation contrôlée des secrets.

Choisissez les nœuds non critiques pour le premier lot. Observez l’enregistrement, la réception des tâches, les échecs de téléchargement, le taux d’échec du workflow et le fonctionnement de la publication. N’élargissez pas le lot parce que le service redémarre correctement : attendez les preuves définies par votre équipe de plateforme.

Le retour arrière doit être pensé comme une reconstruction contrôlée, pas comme une copie improvisée de l’ancien dossier. Conservez l’ancienne image ou le paquet approuvé, la configuration des étiquettes, les dépendances et les journaux. Si une version précédente n’est plus acceptée par GitHub, le retour arrière ne peut pas consister à la remettre en production ; il doit alors viser le dernier état compatible ou un nouveau nœud propre.

La mise à niveau doit finir par une validation de publication

Comment revenir en arrière après un échec de mise à niveau sur Mac ?

Si l’installation échoue avant le démarrage du service, remettez le nœud hors routage, restaurez l’état documenté ou basculez vers le secours. Si le service démarre mais qu’une tâche échoue, ne supprimez pas immédiatement les journaux : conservez l’erreur, l’environnement, la version et l’artefact produit. Rejouez ensuite le workflow sur le nœud de secours afin de distinguer une panne du Runner d’une incompatibilité Xcode, d’un certificat ou d’une dépendance.

Pour une petite équipe, le retour arrière peut être la réactivation de l’ancien nœud après désactivation du nouveau. Pour un parc, privilégiez la création d’un nœud à partir d’une image connue et la réaffectation progressive des étiquettes. Dans les deux cas, la condition de reprise est observable : le nœud doit enregistrer son état, recevoir le workflow attendu et produire un résultat comparable sur le projet réel.

Le responsable de publication valide finalement quatre niveaux, dans cet ordre :

1. le Runner s’enregistre et apparaît au bon niveau de gestion ;
2. le workflow reçoit le nœud par l’étiquette attendue ;
3. la compilation et les tests réussissent sur le véritable projet ;
4. la signature, l’archivage, l’export et la reprise après redémarrage fonctionnent.

Ajoutez une vérification de connexion après redémarrage et une observation des journaux. Si les tests ordinaires réussissent mais que l’archive signée échoue, la migration est refusée. Si la publication fonctionne mais que le nœud ne revient pas après redémarrage, conservez le secours et corrigez le service avant de retirer l’ancien Mac.

À la fin de la fenêtre de changement, choisissez explicitement l’une des trois issues :

• continuer avec le nœud existant, si toutes les preuves sont conformes ;
• reconstruire le nœud, si son historique ou ses permissions sont trop incertains ;
• ajouter temporairement une capacité Mac distante, si la production ne peut pas être interrompue ou si le parc doit être modernisé par étapes.

Décision finale : conserver, reconstruire ou ajouter un Mac distant

Un Mac local utilisé comme Runner reste pertinent si vous maîtrisez son accès physique, ses certificats et son cycle de maintenance. En revanche, il devient fragile lorsqu’il est unique, difficile à arrêter, dépendant d’un poste de développeur ou installé dans un réseau qui empêche les mises à jour vérifiables. Le remplacer directement peut également prolonger l’incident si personne n’a testé la signature et l’archivage.

Dans ce contexte, louer temporairement un Mac via MacDate offre une voie plus prudente pour isoler la migration : vous disposez d’un environnement Mac distant distinct, vous pouvez y reproduire la chaîne minimale et vous évitez de modifier immédiatement le nœud qui publie déjà. Vous pouvez examiner une option de nœud Mac pour la CI selon votre organisation réseau, puis décider après validation si cette capacité doit rester temporaire.

Cette solution n’est toutefois pas idéale pour un besoin de charge lourde stable sur une longue période, pour un accès physique à des périphériques ou pour une équipe qui doit conserver localement une infrastructure amortie. Dans ces cas, l’achat d’un Mac dédié ou la reconstruction d’un parc maîtrisé peut être plus cohérent.

Avant de modifier votre production, faites l’inventaire des Runner, exécutez une bascule de secours et vérifiez une vraie publication. Si votre Mac actuel ne peut pas être arrêté en sécurité, une capacité Mac distante isolée vous permet de tester l’enregistrement, la signature et le projet réel avant de déplacer les étiquettes et les tâches.