Was tun bei einer abgelaufenen GitHub Actions Runner-Version? Mac-Upgrade-Checkliste 2026

Am 12.06.2026 veröffentlichte GitHub den offiziellen Zeitplan zur Durchsetzung von Mindestversionen für selbst gehostete Runner (GitHub-Ankündigung zur Mindestversion). Daraus folgt für Sie: Warten Sie nicht, bis ein Runner keine Aufgaben mehr annimmt.

Symptom → schnellste Lösung: Der Runner wird als „online“ angezeigt, Jobs bleiben aber aus → Mindestversion, Kontotyp, Labels und lokale Logs sofort prüfen.
Wenn ein Produktionsknoten nicht sicher aktualisierbar ist: Einen isolierten Mac-Knoten als Ersatz registrieren, die kleinste reale Buildkette testen und erst danach produktive Labels verschieben.

Zuletzt aktualisiert am 26.08.2026; Datums- und Verhaltensangaben wurden gegen die offizielle GitHub-Ankündigung, die Runner-Dokumentation, die Release-Seite und die Kontohinweise zur Runner-Installation geprüft.

Diese Anleitung ist für drei Gruppen gedacht: Einzelentwickler mit nur einem dauerhaft erreichbaren Mac Runner, kleine Entwicklungsteams mit gemeinsamem Signing- und Xcode-Setup sowie Plattform- und DevOps-Teams mit festen, abgeschotteten oder großen Runner-Pools. Wenn Sie nur einen Runner von Grund auf installieren möchten, ist dies nicht die passende Anleitung: Hier geht es um Versionsprüfung, Upgrade, Abnahme und Rückfall.

Die richtige Reaktion nach Betriebsgröße

Eine abgelaufene GitHub Actions Runner-Version ist nicht dasselbe wie ein gewöhnlicher Workflowfehler. Bei einem fehlerhaften Build können Sie häufig den Quellcode, das Skript oder eine Abhängigkeit untersuchen. Bei einer nicht mehr akzeptierten Runner-Version liegt die Ursache dagegen vor der eigentlichen Ausführung: Der Knoten kann verbunden erscheinen, erhält aber keine neue Aufgabe oder wird aus dem zulässigen Ausführungsbereich genommen.

GitHub unterscheidet dabei nach Verwaltungsebene und Kontotyp. Prüfen Sie deshalb zuerst, ob der Knoten einem Repository, einer Organisation oder einem Enterprise-Cloud-Konto zugeordnet ist. Die offizielle Ankündigung beschreibt die gestaffelte Durchsetzung und die vorgesehenen Zeitpunkte; konkrete Anforderungen dürfen Sie nicht aus alten Suchtreffern übernehmen.

Die wichtigste Unterscheidung lautet: „online“ beschreibt die Erreichbarkeit, nicht die Zulässigkeit. Die offizielle Dokumentation zu selbst gehosteten Runnern sollte deshalb neben dem Konto-Dashboard geöffnet sein. Vergleichen Sie dort nicht nur den Status, sondern auch Version, Runner-Gruppe, Labels und den letzten erfolgreichen Aufgabenzugriff.

Versionsprüfung und Beweiskette

Bevor Sie eine Datei ersetzen, erstellen Sie eine belastbare Beweiskette. Sie verhindert, dass ein späterer Fehler fälschlich dem Upgrade zugeschrieben wird. Schreiben Sie den Knoten, die Verwaltungsebene, die Architektur, den Dienststatus, die Labels und den letzten erfolgreichen Workflow in ein Änderungsprotokoll.

Die aktuelle verfügbare Runner-Version darf in diesem Beitrag nicht als feste Zahl behandelt werden. GitHub kann sie nach dem Veröffentlichungstag ändern. Prüfen Sie sie am Tag der Wartung an drei Stellen:

1. Öffnen Sie die Runner-Übersicht im zuständigen Repository, in der Organisation oder im Enterprise-Konto.
2. Öffnen Sie den dort angezeigten Download- oder Installationshinweis und notieren Sie Paketname, Zielplattform und Aktualisierungshinweise.
3. Vergleichen Sie diese Angabe mit der offiziellen actions/runner-Release-Liste.
4. Sichern Sie die lokalen Runner-Protokolle, den Dienststatus und den Zeitstempel des letzten erfolgreichen Jobs.
5. Lesen Sie die offiziellen Hinweise zur Überwachung und Fehlerdiagnose, bevor Sie Berechtigungen oder Netzwerkprüfungen verändern.

Für eine maschinenlesbare Bestandsaufnahme kann zusätzlich die REST-API-Dokumentation für selbst gehostete Runner sinnvoll sein. Verwenden Sie Organisations- oder Repository-Abfragen aber nur mit den dafür vorgesehenen Berechtigungen. Speichern Sie keine Token in Shell-Historien, Buildlogs oder gemeinsam genutzten Arbeitsverzeichnissen.

Einzelner Mac Runner: Sicherung vor dem Austausch

Wenn Sie nur einen Mac als Mac-Buildknoten besitzen, ist das größte Risiko nicht die Installationsdauer, sondern der vollständige Verlust der Ausführungskapazität. Ein Upgrade auf dem einzigen produktiven Knoten kann Registrierung, Dienst, Zertifikatszugriff, lokale Werkzeuge und Schlüsselbund gleichzeitig berühren.

Sichern Sie vor der Wartung mindestens:

• Runner-Name, Verwaltungsebene und alle Labels;
• Arbeitsverzeichnis und relevante Konfigurationsdateien;
• Dienstdefinition, Startparameter und Dienstkonto;
• Xcode-Auswahl, SDK-Anforderungen und lokale Toolchain;
• Zertifikate, Profile und die erlaubte Schlüsselbund-Nutzung;
• Cache-Verzeichnisse, soweit sie reproduzierbar und datenschutzrechtlich vertretbar sind;
• den letzten erfolgreichen Build einschließlich Artefakt und Log.

Bewahren Sie keine geheimen Schlüssel unverschlüsselt als vermeintliche „Sicherung“ auf. Prüfen Sie außerdem, ob ein Build tatsächlich auf den erwarteten Schlüsselbund zugreifen darf. Ein Test, der nur kompiliert, aber nicht signiert oder archiviert, ist für eine Release-Pipeline unzureichend.

Die robuste Reihenfolge besteht aus fünf Arbeitsphasen:

1. Kapazität reservieren: Stellen Sie einen isolierten Mac-Knoten bereit oder verlagern Sie nichtkritische Tests vorübergehend auf eine andere zulässige Ausführungsumgebung. Wenn der Produktionsknoten nicht abgeschaltet werden darf, ist ein zusätzlicher Mac-Rechenknoten für getrennte Buildaufgaben die sauberere Absicherung als ein direktes Überschreiben.
2. Minimalzustand reproduzieren: Installieren Sie nur die für einen repräsentativen Workflow erforderlichen Werkzeuge. Kopieren Sie keine unbekannten Zustände blind vom Produktionsknoten.
3. Runner registrieren: Verwenden Sie einen kurzlebigen, für den jeweiligen Geltungsbereich erzeugten Registrierungsvorgang. Organisation, Repository und Token bleiben Platzhalter: <ORGANISATION>, <REPOSITORY> und <TOKEN>.
4. Labels und Dienst prüfen: Führen Sie einen Workflow mit dem echten Label aus, starten Sie den Mac-Knoten neu und prüfen Sie, ob der Dienst danach wieder registriert ist.
5. Echten Releasepfad ausführen: Bauen, testen, signieren und archivieren Sie ein reales Projekt. Erst wenn Log und Artefakt stimmen, verschieben Sie produktive Aufgaben.

Stoppen Sie den Rollout, sobald Registrierung, Label-Routing, Neustart oder Signatur fehlschlägt. Ein zweiter Installationsversuch auf demselben Knoten ist kein Rückfallplan.

Gemeinsame Teamknoten: Graustufen statt Komplettwechsel

In kleinen Teams teilen sich mehrere Repositories häufig eine Xcode-Version, Caches, Zertifikate und feste Labels. Dadurch kann ein scheinbar erfolgreiches Runner-Upgrade einen anderen Workflow beschädigen. Erfassen Sie vorab, welche Projekte auf ein bestimmtes Label, eine bestimmte SDK-Version oder einen lokalen Cache angewiesen sind.

Wählen Sie für die erste Gruppe einen nichtkritischen Knoten. Lassen Sie dort einen repräsentativen Workflow pro Risikoklasse laufen: ein reiner Testlauf, ein signierter Build und ein Archivlauf. Die Prüfungen sollten mit denselben Repository-Berechtigungen und denselben geschützten Variablen erfolgen wie später in der Produktion.

Vergleichen Sie vor und nach dem Upgrade:

• Runner-Version und Dienstprotokoll;
• Job-Annahme, Warteschlangenzeit und Label-Zuordnung;
• verwendete Xcode- und SDK-Ausgabe;
• Testresultate und erzeugte Artefakte;
• Zugriff auf Schlüsselbund, Zertifikate und Profile;
• Verhalten nach einem Neustart;
• Rückkehr zum vorherigen Knoten bei absichtlich ausgelöstem Fehler.

Übernehmen Sie danach zuerst ein Repository mit niedriger Veröffentlichungsrelevanz. Erst wenn dessen Ergebnis nachvollziehbar ist, folgen weitere Projekte. Signing- und Release-Workflows kommen zuletzt, weil dort ein grüner Kompilierungsschritt allein keine ausreichende Aussage liefert.

Deaktivierte Updates und eingeschränkte Netzwerke

Ein fester Runner-Stand kann aus Gründen der Reproduzierbarkeit sinnvoll sein, wird aber zur Betriebsverantwortung. „Automatische Aktualisierung deaktiviert“ bedeutet nicht, dass der Knoten von der Mindestversion-Durchsetzung ausgenommen ist. Sie benötigen einen dokumentierten manuellen Aktualisierungsweg.

Prüfen Sie in dieser Reihenfolge:

• Erreicht der Knoten die für Download und Registrierung erforderlichen GitHub-Endpunkte über den Proxy?
• Wird das Paket aus einer vertrauenswürdigen offiziellen Quelle bezogen?
• Können Sie Prüfinformationen und Paketversion einem Änderungsdatensatz zuordnen?
• Darf das Dienstkonto Dateien ersetzen, Prozesse neu starten und Logs schreiben?
• Werden Proxyfehler, TLS-Probleme, Zugriffsfehler und Neustarts vollständig protokolliert?
• Gibt es eine getestete Rückkehr auf einen funktionsfähigen Ersatzknoten?

Schalten Sie die TLS-Prüfung nicht als gewöhnliche Reparaturmaßnahme ab. Eine Ausnahme kann die Vertrauenskette schwächen und muss, falls sie in einer kontrollierten Diagnose überhaupt erforderlich ist, mit Risiko, Zeitfenster, Verantwortlichem und Rücknahme dokumentiert werden. Besser ist es, die Zertifikatskette, Proxy-Konfiguration und Systemzeit korrekt zu prüfen.

Bei dauerhaft eingeschränkter Außenanbindung sollten Sie ein Paket nicht einfach manuell auf mehrere Knoten kopieren. Legen Sie eine interne, zugriffsbeschränkte Verteilung mit Herkunftsnachweis an und halten Sie die ursprüngliche Quelle, Prüfinformation und Freigabe fest. Für DSGVO-relevante Projekte gehören außerdem Logs, Zertifikate und Quellartefakte in klar definierte Aufbewahrungs- und Zugriffsregeln.

FAQ für die Betriebsunterbrechung

Wie sehen Sie die Version eines selbst gehosteten Runners?

Öffnen Sie zuerst die Runner-Ansicht auf der zuständigen Verwaltungsstufe und vergleichen Sie die Anzeige mit dem aktuellen Installationshinweis und der offiziellen Release-Liste. Kontrollieren Sie anschließend die lokale Runner-Ausgabe, den Dienststatus und die Diagnoseprotokolle. Nur wenn diese Informationen zusammenpassen, können Sie den Versionsstand als belastbaren Nachweis für ein Upgrade verwenden.

Was ändert sich bei abgeschalteter automatischer Aktualisierung?

Dann liegt die Aktualisierungsverantwortung bei Ihrem Team. Prüfen Sie Netzwerkweg, Proxy, Paketquelle, Prüfinformationen, Dienstkonto und Logaufbewahrung. Installieren Sie den neuen Stand zuerst isoliert und testen Sie Registrierung, Labels, Neustart und einen echten Build. Verwenden Sie keine Deaktivierung der TLS-Prüfung als dauerhafte Lösung, weil dadurch die Absicherung des Downloadwegs geschwächt werden kann.

Weshalb ist der alte Runner noch online?

Das Online-Symbol zeigt nur, dass der Runner-Dienst eine Verbindung aufrechterhält. Es bestätigt weder die aktuell erlaubte Runner-Version noch die passende Runner-Gruppe oder Label-Zuordnung. Bei einer Mindestversionsprüfung kann GitHub einen verbundenen, aber nicht mehr zulässigen Knoten von neuen Aufgaben fernhalten. Prüfen Sie daher offizielle Hinweise und lokale Logs statt nur das Dashboard.

Wie rollen Sie ein fehlgeschlagenes Mac-Upgrade zurück?

Sperren Sie zunächst die weitere Job-Zuweisung auf dem fehlerhaften Knoten und sichern Sie alle Logs. Wechseln Sie dann auf einen vorbereiteten Ersatzknoten, dessen Registrierung, Labels, Signatur und Neustart bereits geprüft wurden. Reparieren Sie den alten Knoten erst außerhalb des Produktionspfads. Der Rückfall gilt erst als erfolgreich, wenn ein echter Workflow wieder ein erwartetes Artefakt erzeugt.

Enterprise-Pools: Inventar, Wellen und Audit

Bei vielen Knoten ist eine Einzelprüfung nicht ausreichend. Erstellen Sie eine Liste nach Runner-Gruppe, Architektur, Labels, Repository-Berechtigung, automatischer Aktualisierung und Versionsstand. Ergänzen Sie Kritikalität und Lebenszyklus: Ein kurzlebiger Knoten kann bei jedem Einsatz neu aufgebaut werden, während ein langlebiger Knoten eine dokumentierte Wartung und einen Ersatzpfad benötigt.

Teilen Sie den Rollout in drei kontrollierte Phasen:

1. Test: Nichtkritische Knoten erhalten das Upgrade. Sie prüfen Registrierung, Jobannahme, Toolchain, Artefakte und Neustart.
2. Erweiterung: Eine begrenzte Produktionsgruppe folgt. Sie beobachten fehlgeschlagene Jobs, Routing, Signatur und Veröffentlichungen.
3. Rückfall oder Freigabe: Bei Abweichungen wechseln Sie die Labels oder Runner-Gruppe auf den Ersatz. Bei stabilen Ergebnissen dokumentieren Sie die Freigabe und setzen die nächste Gruppe an.

Automatisch skalierende Knoten sollten möglichst unveränderlich behandelt werden: Aktualisieren Sie das Ausgangsimage oder die Provisionierungsdefinition und ersetzen Sie Instanzen kontrolliert. Bei langfristig betriebenen Knoten müssen Sie dagegen lokale Zustände wie Schlüsselbund, Cache und Dienstkonto separat prüfen. Diese Strategien dürfen nicht vermischt werden, weil ein Image-Rollout andere Fehlerbilder erzeugt als ein In-place-Upgrade.

Für jeden Knoten oder jede Welle gehören folgende Informationen in den Auditdatensatz:

• Ausgangs- und Zielversion;
• Zeitpunkt, Verantwortlicher und Änderungsgrund;
• verwendete Quelle und Prüfnachweis;
• betroffene Labels und Runner-Gruppen;
• erfolgreiche und fehlgeschlagene Workflow-IDs;
• Build- und Signaturartefakte;
• Ergebnis des Neustart- und Rückfalltests;
• Entscheidung: fortsetzen, pausieren oder zurückrollen.

Release-Abnahme: Produktionsfähigkeit statt grünes Testlicht

Die letzte Entscheidung trifft nicht die Versionsanzeige, sondern der reale Veröffentlichungsweg. Ein Runner kann Jobs annehmen und Unit-Tests ausführen, während Archivierung, Codesignatur oder Export weiterhin scheitern. Beziehen Sie deshalb den Release-Verantwortlichen früh in die Abnahme ein.

Verwenden Sie diese Reihenfolge als Freigabeliste:

1. Runner registriert sich nach Neustart wieder.
2. Das erwartete Label nimmt den vorgesehenen Job an.
3. Ein echter Xcode-Build läuft mit der produktiven Toolchain.
4. Tests erzeugen nachvollziehbare Ergebnisse.
5. Signatur und Profilzugriff funktionieren mit den vorgesehenen Rechten.
6. Ein Archiv wird erstellt und kann im vorgesehenen Prozess weiterverwendet werden.
7. Logs, Artefakt und Runner-Version sind dem Änderungsdatensatz zugeordnet.
8. Der Ersatz- oder Rückfallweg wurde praktisch ausgeführt.

Wenn nur der Testlauf erfolgreich ist, pausieren Sie die Umstellung. Wenn die Registrierung scheitert, wechseln Sie auf den Ersatzknoten. Wenn der Knoten zwar baut, aber Signing oder Archivierung fehlschlägt, bleibt das alte Produktionsrouting aktiv, bis die Ursache geklärt ist.

Für einen langfristigen Mac-Betrieb sollten Sie außerdem zwischen physischer Ausführung und Virtualisierung unterscheiden. Der Beitrag Bare Metal oder macOS-Virtualisierung hilft bei der Bewertung von Host-Rechten, Gerätezugriff, Stabilität und Wiederherstellbarkeit. Für Apple-spezifische CI/CD-Aufgaben ist diese Entscheidung wichtiger als ein bloßes Online-Signal.

Entscheidung nach der Abnahme

Nach den Tests gibt es drei sachliche Optionen:

• Bestehenden Knoten weiterverwenden: Alle Prüfungen sind erfolgreich, der Updateweg ist dokumentiert und ein Rückfallpfad bleibt verfügbar.
• Knoten neu aufbauen: Der alte Zustand enthält nicht reproduzierbare Werkzeuge, unklare Rechte oder eine beschädigte Dienstinstallation. Ein sauberer Neuaufbau ist dann sicherer als weitere Reparaturversuche.
• Vorübergehend zusätzliche Mac-Kapazität mieten: Der Produktionsknoten darf nicht ausfallen, die Aktualisierung muss aber vor dem nächsten Durchsetzungszeitpunkt geprüft werden. Ein isolierter Mac von MacDate kann dabei als getrennte Test- und Ausweichumgebung dienen; die produktive Umschaltung erfolgt erst nach erfolgreicher Registrierung, Signatur und echtem Projekt-Build.

Ihre bisherige Lösung bleibt möglicherweise kurzfristig bequem, wenn ein einzelner lokaler Mac-Knoten gut bekannt ist. Sie hat jedoch drei reale Schwächen: Wartung blockiert bei nur einem Knoten die gesamte Pipeline, lokale Zustände wie Schlüsselbund und Toolchain sind schwer reproduzierbar, und ein veralteter Runner kann trotz Online-Anzeige unbemerkt aus dem zulässigen Ausführungsbereich fallen. Ein isolierter, gemieteter Mac-Knoten ist deshalb für Upgrade-Tests und zeitkritische Ausweichkapazität oft die kontrollierbarere Lösung als ein riskanter Eingriff in die Produktionsmaschine.

Beginnen Sie mit einer Bestandsliste und einer einmaligen Ersatzknoten-Umschaltung. Wenn Ihr vorhandener Mac nicht sicher angehalten werden kann, reproduzieren Sie die kleinste echte Buildkette auf einem MacDate-Knoten, prüfen Sie danach Registrierung, Labels, Signing, Archivierung und Neustart und verschieben Sie erst dann die produktiven Aufgaben.