GitHub Actions : éviter le blocage des runners

Les runners auto-hébergés GitHub Actions doivent désormais rester réellement à jour pour continuer à prendre des jobs. Depuis le 25 septembre 2026, l’application complète des exigences de version concerne GitHub Enterprise Cloud. Le risque n’est pas seulement un échec de mise à jour : un runner déjà enregistré peut rester en attente ou cesser d’exécuter un workflow si son niveau n’est plus accepté.

Ce que change le minimum de version des runners

GitHub distingue deux seuils. La version 2.329.0 est requise pour configurer ou réenregistrer un runner sur la nouvelle architecture. Mais elle ne constitue pas un socle durable pour exécuter les jobs : chaque nouvelle version du runner doit être installée dans les 30 jours suivant sa publication. Un runner figé sur un ancien binaire peut donc sembler disponible tout en ne recevant plus de travail.

Cette règle s’applique à github.com, y compris GitHub Enterprise Cloud et son offre Data Residency ; GitHub Enterprise Server n’est pas concerné à ce stade. Pour une équipe produit, il faut donc relier le sujet à la plateforme réellement utilisée au lieu de généraliser une consigne cloud à tous les environnements GitHub.

Faire l’inventaire avant que la livraison ne s’arrête

Ne pas confondre machine connectée et runner maintenu

Commencez par recenser les runners par organisation, dépôt, système et image de base. Les journaux d’audit peuvent aider à repérer les versions lors des enregistrements, mais ils ne remplacent pas un inventaire de tous les agents connectés. Ajoutez les runners éphémères, les groupes de scale set, les VM de secours et les conteneurs créés par une automatisation : ce sont souvent eux qui redémarrent sur une image vieillissante.

1. Classez les flux critiques. Isolez ceux qui livrent en production, signent des artefacts ou gèrent des secrets.
2. Vérifiez la mise à jour automatique. Elle respecte la cadence si le runner peut joindre le service de mise à jour ; une règle réseau trop restrictive peut la neutraliser.
3. Corrigez les images à la source. Mettez à jour scripts d’installation, images VM, conteneurs et modèles d’infrastructure, plutôt que de réparer chaque instance à la main.
4. Testez un vrai workflow. Contrôlez la prise en charge du job, les artefacts et la notification finale, pas seulement la présence « online » du runner.

Une alerte opérationnelle, pas une migration isolée

Les annotations de job et les API de GitHub donnent des signaux, mais l’objectif métier reste simple : détecter un écart avant qu’un déploiement urgent ne soit mis en file. Un tableau de suivi peut réunir version observée, date de dernière mise à jour, image d’origine, propriétaire et dernier workflow représentatif réussi. La décision devient alors vérifiable : mettre à jour, reconstruire l’image ou retirer un runner devenu inutile.

Cette discipline complète la migration des actions JavaScript vers Node 24 : l’une porte sur le runtime d’une action, l’autre sur l’agent qui reçoit le job. Les traiter dans la même fenêtre de maintenance limite les surprises, sans mélanger leurs critères de validation.

Préserver la continuité de vos runners auto-hébergés

Le changelog officiel de GitHub détaille les exigences, l’échéance et les actions recommandées. En transformant ce changement en contrôle récurrent d’images et de runners, vous rendez la CI/CD plus prévisible au lieu d’attendre le premier job bloqué.