Les runners auto-hébergés GitHub Actions cessent de recevoir des jobs le 25 septembre

14 septembre 2026. Les brownouts commencent : les runners obsolètes échouent par intermittence à s’enregistrer. 16 et 18 septembre. Les deux fenêtres de brownout suivantes. 25 septembre 2026. L’application dure : plus aucun job n’est envoyé à un runner auto-hébergé qui n’a pas été mis à jour sous 30 jours. Pourquoi c’est important : l’échec est silencieux — pas d’erreur dans vos workflows, juste des jobs qui restent « Queued » indéfiniment.

Ce que GitHub a changé sous le capot

GitHub a reconstruit le backend de Actions de zéro. L’ancienne plateforme traitait environ 23 millions de jobs par jour ; la nouvelle en absorbe 120 millions ou plus — plus de cinq fois le volume — et permet de démarrer sept fois plus de jobs par minute. Les anciennes versions de runner ne peuvent pas communiquer avec la nouvelle infrastructure : c’est une incompatibilité technique, pas un choix de politique.

En conséquence, GitHub fixe une version minimale (2.329.0) et une règle glissante : tout runner doit être mis à jour dans les 30 jours suivant chaque nouvelle release, sous peine de cesser de recevoir des jobs. L’application a déjà été repoussée deux fois — de décembre 2025 à mars 2026, puis à septembre 2026. Il n’y a plus de prolongation sur la table.

Qui est réellement exposé

La plupart des runners se mettent à jour automatiquement par défaut. Si vous n’avez pas explicitement désactivé les mises à jour, il y a de bonnes chances que vous soyez déjà en règle. Le vrai danger vient des runners qui ont opté pour la désactivation :

• Runners lancés avec --disableupdate — fréquents dans les images Docker, les charts Helm et les modules Terraform écrits il y a des mois. Le flag est souvent enfoui et oublié.
• Runners conteneurisés (Kubernetes/ARC) — le champ runnerVersion d’une spec RunnerDeployment ou AutoscalingRunnerSet doit être remonté explicitement.
• Runners air-gapped — incapables de télécharger les mises à jour automatiquement ; chaque release exige un processus manuel.
• Runners orphelins — configurés par quelqu’un qui a quitté l’équipe, épinglés à une ancienne version, jamais revisités.

Le flag --disableupdate était un choix raisonnable pour qui voulait contrôler son environnement de build. Il crée désormais une dette d’entretien obligatoire : mettre à jour à la main sous 30 jours à chaque release. Pour la plupart des équipes, c’est un pire compromis que la mise à jour automatique.

Comment auditer avant le 25

Le changelog du 3 septembre a livré une API REST dédiée, disponible aux niveaux dépôt, organisation et entreprise :

# Dates exactes de dépréciation pour une version de runner donnée
curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \
  "https://api.github.com/orgs/ACME/actions/runners/deprecations/2.323.0"

La réponse renvoie runtime_deprecates_at et registration_deprecates_at — un runner peut cesser d’accepter de nouvelles inscriptions avant de cesser de s’exécuter. Pour lister tous les runners d’une organisation avec leur version :

gh api "/orgs/ACME/actions/runners" \
  --jq '.runners[] | {name: .name, version: .version}'

Vous pouvez aussi passer par Settings → Actions → Runners dans l’interface : cliquez sur un runner pour voir sa version.

Comment corriger

Si vos runners se mettent à jour automatiquement, ils devraient déjà être à jour : vérifiez et passez à autre chose. Si vous avez des runners en --disableupdate :

# 1. Arrêter le service du runner
sudo ./svc.sh stop

# 2. Remplacer le binaire par la dernière release
curl -o runner.tar.gz -L https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64-2.329.0.tar.gz
tar xzf runner.tar.gz
./config.sh --url https://github.com/ACME/REPO --token "$RUNNER_TOKEN"
sudo ./svc.sh start

Pour actions-runner-controller (ARC) : fixez runnerVersion: latest dans votre spec AutoscalingRunnerSet, ou épinglez une version supérieure à 2.329.0, puis redéployez.

Le calendrier des brownouts restant — 16 septembre, 18 septembre, puis 25 septembre en application dure — laisse onze jours. Les brownouts ont déjà commencé : vérifiez vos runners avant la prochaine fenêtre.

Ce que la bascule dit de votre dépendance au CI

Derrière l’aspect procédural, cet épisode est un rappel que le CI/CD est une infrastructure de production comme une autre. Un runner auto-hébergé est un nœud qui exécute du code arbitraire avec vos secrets — KUBECONFIG, clés AWS, jetons de registre. Le fait qu’un runner obsolète puisse échouer silencieusement — des jobs « Queued » sans aucune erreur — transforme une simple négligence de version en panne sournoise, découverte des heures après le commit.

C’est aussi une illustration de la dette du self-hosting de build. Ceux qui ont choisi --disableupdate pour la stabilité héritent aujourd’hui d’une charge manuelle ; ceux qui laissent la mise à jour automatique acceptent qu’un changement de version puisse arriver à tout moment en plein run. Il n’y a pas de bonne option universelle — il y a un choix à assumer et à instrumenter : soit automatiser les mises à jour avec une fenêtre de contrôle, soit brancher l’API de dépréciation dans la supervision pour programmer les montées de version avant l’échéance.

Détecter l’échec silencieux

Le caractère sournois de cette échéance tient à son mode de panne. Un runner qui n’est plus éligible ne produit aucune erreur : le workflow reste déclenché, mais le job s’accumule dans l’état « Queued » sans jamais démarrer. Une équipe qui ne supervise pas activement la longueur de sa file d’attente découvrira la panne quand quelqu’un demandera pourquoi la livraison n’est pas partie — pas quand elle s’est produite.

Deux signaux simples méritent d’être branchés avant le 25 septembre. Le premier est la durée de séjour en « Queued » : une alerte qui se déclenche quand un job attend plus de quelques minutes est un détecteur générique d’infrastructure de build malade, échéance de runner comprise. Le second est l’API de dépréciation elle-même : un job quotidien qui interroge GET /actions/runners/deprecations/{version} pour chaque version déployée et compare runtime_deprecates_at à la date du jour transforme la mise à niveau en opération planifiée plutôt qu’en course contre la montre.

L’échec silencieux a une seconde conséquence, moins visible : il érode la confiance dans le statut vert. Si un pipeline peut être « vert » avec des jobs qui n’ont jamais tourné, le vert cesse d’être une preuve. Pour les équipes qui attachent des garanties de conformité au passage du CI — build signé, scan de dépendances, déploiement attesté — un runner fantôme est une brèche dans la chaîne de preuve, pas seulement une gêne opérationnelle.

Les cas ARC et air-gapped

Deux populations méritent un regard avant l’échéance. Les utilisateurs d’actions-runner-controller (ARC) gèrent leurs runners via des specs Kubernetes plutôt qu’un binaire sur une VM : le chemin de mise à niveau n’est pas « lancer un script » mais « modifier un RunnerDeployment ou un AutoscalingRunnerSet et redéployer ». Le champ runnerVersion est épinglé par défaut ; le passer à latest supprime la montée manuelle, mais accepte qu’une nouvelle release puisse traverser le cluster à tout moment. Épingler au-dessus de 2.329.0 avec une cadence de revue planifiée est le compromis pour qui veut le contrôle et la conformité.

Les runners air-gapped sont le cas le plus lourd. Ils ne peuvent pas joindre le service de mise à jour : chaque release exige de télécharger le paquet sur une machine connectée, de le transférer dans le réseau et de relancer config.sh avec un jeton d’inscription neuf. La règle des 30 jours transforme cela en tâche opérationnelle permanente. Si vous exploitez du build air-gapped, l’échéance n’est pas le 25 septembre : c’est une horloge de 30 jours que vous possédez désormais, et la seule réponse durable est d’automatiser le transfert ou de basculer vers un pool de runners géré.

Verdict

Si vous gérez des runners auto-hébergés, ne supposez rien : auditez les versions dès maintenant via l’API de dépréciation ou l’interface, et traitez tout runner sous 2.329.0 ou non mis à jour sous 30 jours comme un incident programmé. Si vous utilisez ARC, remontez runnerVersion avant le 25 septembre. Et si vous hébergez du build air-gapped ou orphelin, c’est le moment de remettre en question cette architecture : une infrastructure de build qui exige une intervention manuelle à chaque release est une panne en attente, pas un choix de contrôle.

Références

• GitHub Changelog — GitHub Actions minimum version enforcement timeline for self-hosted runners, 12 juin 2026
• GitHub Changelog — GitHub Actions: Early September 2026 updates, 3 septembre 2026
• DevOps.com — GitHub Actions Gets Serious About Self-Hosted Runner Versions
• GitHub Docs — Actions: runner deprecations API