GitHub Actions blockiert selbst gehostete Runner unter 2.329.0

GitHub hat am 29. September 2026 mit der vollständigen Durchsetzung seiner Mindestversionsregel für selbst gehostete Actions-Runner begonnen. Ein Changelog-Beitrag von GitHub verschob das Datum vom 25. September. Runner, die älter als Version 2.329.0 sind, können sich nicht mehr bei GitHub Enterprise Cloud registrieren. Veraltete Runner, die bereits registriert sind, nehmen keine Jobs mehr an.

Ein selbst gehosteter Runner ist das kleine Programm, das ein Team auf seinem eigenen Rechner installiert, um GitHub-Actions-Workflows auszuführen, statt die gehosteten Maschinen von GitHub zu nutzen. Teams setzen sie für spezielle Hardware, private Netzwerke oder geringere Kosten ein. Ein Runner, der einmal installiert und nie aktualisiert wurde, kann jetzt eine CI-Pipeline, das automatisierte Build- und Testsystem, ganz ohne Codeänderung stoppen.

Die zwei Versionsregeln

Es gelten zwei getrennte Grenzen, laut GitHubs Zeitplan-Beitrag vom 12. Juni 2026.

Regel	Was sie verlangt	Was passiert, wenn Sie sie verfehlen
Registrierung	Runner-Version 2.329.0 oder neuer	Der Runner kann sich nicht registrieren oder neu registrieren
Job-Ausführung	Jedes neue Runner-Release innerhalb von 30 Tagen nach seiner Veröffentlichung installiert	Der Runner führt keine Jobs mehr aus, auch wenn er bereits registriert ist

Die Job-Regel ist die strengere der beiden. Ihre Mindestversion liegt über dem Registrierungsminimum, und sie verschiebt sich laufend. Ein Runner kann neu genug sein, um sich zu registrieren, und trotzdem zu alt, um einen Workflow auszuführen.

Wer betroffen ist

Die Regel gilt für GitHub.com und GitHub Enterprise Cloud, GitHubs gehosteten Dienst für Unternehmen. GitHub Enterprise Cloud mit Datenresidenz, die Edition, die Daten in einer gewählten Region hält, setzt sie seit dem 31. Juli 2026 durch. GitHub Enterprise Server, das Produkt, das Unternehmen auf eigenen Servern installieren, ist nicht betroffen.

Wie es zu diesem Rollout kam

GitHub veröffentlichte den Zeitplan im Juni und führte dann Brownouts durch. Ein Brownout ist eine kurze, geplante Sperre, die alte Runner für einige Stunden abschaltet, damit ihre Besitzer es vor der echten Frist bemerken.

Für Enterprise Cloud liefen die Brownouts an festgelegten Tagen von 11:00 bis 15:00 Uhr Eastern Time. Sie wurden jede Woche ausgeweitet, laut dem Juni-Beitrag.

Woche	Brownout-Tage	Was gesperrt wurde
1	24. August	Registrierung
2	31. August, 2. September	Registrierung
3	7., 9., 11. September	Registrierung und Ausführen von Jobs
4	14., 16., 18. September	Registrierung und Ausführen von Jobs

Der Grund für die Regel ist die Infrastruktur. DevOps.com berichtet, dass GitHub Anfang 2024 begann, die Backend-Dienste hinter Actions neu aufzubauen. Die neue Plattform verarbeitet mehr als 120 Millionen Jobs pro Tag. Sie erlaubt Unternehmen außerdem, siebenmal mehr Jobs pro Minute zu starten als zuvor. Die Durchsetzung der Runner-Versionen schließt diese Migration ab, indem sie sicherstellt, dass jeder Runner auf der neuen Plattform funktioniert, schreibt DevOps.com.

Ihre Runner prüfen

GitHubs Beitrag vom 28. September fügt außerdem eine REST API für Abkündigungen von Runner-Versionen hinzu. Sie liefert die Abkündigungsdaten für Registrierung und Laufzeit von Runner-Versionen. Ein Team kann damit die nächste Frist kommen sehen, statt durch einen fehlgeschlagenen Job davon zu erfahren.

Runner mit eingeschalteten automatischen Updates erfüllen die 30-Tage-Regel von selbst, sagt GitHubs Juni-Beitrag. Runner, die jemand von Hand aktualisiert, brauchen einen regelmäßigen Update-Plan, um im Fenster zu bleiben.

Was das für Entwickler bedeutet

Prüfen Sie heute jeden selbst gehosteten Runner, bevor ein Build fehlschlägt. Erstellen Sie eine Liste aller Runner und der Version, die jeder meldet, und aktualisieren Sie zuerst alles unter 2.329.0. Diese Maschinen sind von der Registrierung bereits ausgesperrt.

Sehen Sie sich dann an, wie jeder Runner seine Updates bekommt. Runner, die in das Image einer virtuellen Maschine oder in ein Container-Image eingebacken sind, sind die übliche Falle. Sie starten mit der Version, die im Image eingefroren wurde. Teams schalten automatische Updates oft ab, damit Builds reproduzierbar bleiben. Bei einem 30-Tage-Fenster muss dieses Image jetzt mindestens einmal im Monat neu gebaut werden.

Behandeln Sie die Regel als dauerhaft, nicht als einmalige Migration. Jedes neue Runner-Release startet eine neue 30-Tage-Uhr. Nehmen Sie die Runner-Version in dieselbe Patch-Routine auf wie das Betriebssystem, und binden Sie die Abkündigungs-API in Ihr Monitoring ein.

Achten Sie auf Runner, die still werden. Vor dieser Regel bedeutete ein untätiger Runner meist eine defekte Maschine. Jetzt kann es heißen, dass GitHub ihm einfach keine Jobs mehr schickt.