GitHub Actions bloque les runners auto-hébergés antérieurs à 2.329.0

GitHub a commencé à appliquer pleinement sa règle de version minimale pour les runners Actions auto-hébergés le 29 septembre 2026. Un billet du changelog de GitHub a déplacé la date, auparavant fixée au 25 septembre. Les runners antérieurs à la version 2.329.0 ne peuvent plus s'enregistrer auprès de GitHub Enterprise Cloud. Les runners obsolètes déjà enregistrés cessent de prendre des jobs.

Un runner auto-hébergé est le petit programme qu'une équipe installe sur sa propre machine pour exécuter des workflows GitHub Actions, au lieu d'utiliser les machines hébergées par GitHub. Les équipes s'en servent pour du matériel spécial, des réseaux privés ou un coût plus bas. Un runner installé une fois et jamais mis à jour peut désormais arrêter un pipeline de CI, le système automatisé de build et de test, sans le moindre changement de code.

Les deux règles de version

Deux limites distinctes s'appliquent, selon le billet de calendrier publié par GitHub le 12 juin 2026.

Règle	Ce qu'elle exige	Ce qui se passe si vous la manquez
Enregistrement	Version du runner 2.329.0 ou ultérieure	Le runner ne peut ni s'enregistrer ni se réenregistrer
Exécution des jobs	Chaque nouvelle version du runner installée dans les 30 jours suivant sa publication	Le runner cesse d'exécuter des jobs, même s'il est déjà enregistré

La règle sur les jobs est la plus stricte des deux. Sa version minimale se situe au-dessus du minimum d'enregistrement, et elle ne cesse d'avancer. Un runner peut être assez récent pour s'enregistrer et pourtant trop ancien pour exécuter un workflow.

Qui est concerné

La règle couvre GitHub.com et GitHub Enterprise Cloud, le service hébergé de GitHub pour les entreprises. GitHub Enterprise Cloud avec résidence des données, l'édition qui conserve les données dans une région choisie, l'applique depuis le 31 juillet 2026. GitHub Enterprise Server, le produit que les entreprises installent sur leurs propres serveurs, n'est pas concerné.

Comment le déploiement en est arrivé là

GitHub a publié le calendrier en juin, puis a organisé des brownouts. Un brownout est un blocage court et planifié qui coupe les anciens runners pendant quelques heures, pour que leurs propriétaires s'en aperçoivent avant la vraie échéance.

Pour Enterprise Cloud, les brownouts ont eu lieu de 11 h à 15 h, heure de l'Est des États-Unis, à des jours fixés. Ils se sont étendus chaque semaine, selon le billet de juin.

Semaine	Jours de brownout	Ce qui était bloqué
1	24 août	Enregistrement
2	31 août, 2 septembre	Enregistrement
3	7, 9 et 11 septembre	Enregistrement et exécution des jobs
4	14, 16 et 18 septembre	Enregistrement et exécution des jobs

La raison de la règle tient à l'infrastructure. DevOps.com rapporte que GitHub a commencé à reconstruire les services backend d'Actions début 2024. La nouvelle plateforme traite plus de 120 millions de jobs par jour. Elle permet aussi aux entreprises de lancer sept fois plus de jobs par minute qu'auparavant. Imposer les versions des runners achève cette migration en garantissant que chaque runner fonctionne sur la nouvelle plateforme, selon DevOps.com.

Vérifier vos runners

Le billet de GitHub du 28 septembre ajoute aussi une REST API pour les dépréciations de versions du runner. Elle renvoie les dates de dépréciation à l'enregistrement et à l'exécution pour les versions du runner. Une équipe peut s'en servir pour voir venir la prochaine échéance, plutôt que de l'apprendre par un job en échec.

Les runners dont les mises à jour automatiques sont activées respectent d'eux-mêmes la règle des 30 jours, indique le billet de juin de GitHub. Les runners que quelqu'un met à niveau à la main ont besoin d'un calendrier de mises à jour régulier pour rester dans la fenêtre.

Ce que cela signifie pour les développeurs

Vérifiez aujourd'hui chaque runner auto-hébergé, avant qu'un build échoue. Dressez la liste de chaque runner et de la version qu'il indique, et mettez d'abord à niveau tout ce qui est sous 2.329.0. Ces machines sont déjà exclues de l'enregistrement.

Regardez ensuite comment chaque runner reçoit ses mises à jour. Les runners intégrés à une image de machine virtuelle ou à une image de conteneur sont le piège habituel. Ils démarrent avec la version figée dans l'image. Les équipes désactivent souvent les mises à jour automatiques pour garder des builds reproductibles. Avec une fenêtre de 30 jours, cette image doit désormais être reconstruite au moins une fois par mois.

Traitez la règle comme permanente, pas comme une migration ponctuelle. Chaque nouvelle version du runner lance un nouveau compte à rebours de 30 jours. Intégrez la version du runner à la même routine de correctifs que le système d'exploitation, et branchez l'API de dépréciation sur votre supervision.

Surveillez les runners qui se taisent. Avant cette règle, un runner inactif signalait en général une machine en panne. Désormais, cela peut vouloir dire que GitHub a simplement cessé de lui envoyer des jobs.