Was tun, wenn die Version des selbstgehosteten GitHub Actions Mac Runners veraltet ist? Reparaturanleitung 2026

Die Durchsetzung betrifft nicht jede GitHub-Installation gleich. Außerdem gibt es zwei verschiedene Fragen: Darf ein Runner mit seiner installierten Version registriert oder erneut registriert werden? Und wird diese Version noch für die Ausführung von Workflows unterstützt? Werden diese Prüfungen vermischt, kann ein Knoten zwar bereits registriert sein, aber dennoch veraltete Laufzeitsoftware verwenden.

Die Zahl 2.329.0 bezeichnet daher eine Registrierungsschwelle im genannten Geltungsbereich, nicht eine dauerhafte Freigabe für den produktiven Betrieb. GitHub entwickelt die Laufzeitunterstützung weiter. Richten Sie die operative Entscheidung deshalb nach der aktuellen API-Antwort und nicht allein nach einer festen Zahl aus. Die Dokumentation zu selbstgehosteten Runnern beschreibt Aktualisierung und Versionsverwaltung; die REST-API zur Außerdienststellung liefert den versionsbezogenen Status.

Wichtig: „Online“ ist kein Abnahmenachweis. Es sagt nicht zuverlässig aus, ob die installierte Version noch Workflows ausführen darf, ob der Runner für die betroffene Warteschlange erreichbar ist oder ob sein Toolchain-Zustand einen erfolgreichen Build ermöglicht.

Erstellen Sie eine Bestandsliste, bevor Sie Software aktualisieren oder Knoten neu registrieren. Sie sollte nicht nur den Runner-Namen enthalten, sondern auch den Ort seiner Verwaltung, die Installationsquelle und den tatsächlichen Arbeitsablauf. So werden alte Installationsskripte oder Images sichtbar, die einen aktualisierten Knoten beim nächsten Austausch wieder auf einen früheren Stand zurücksetzen könnten.

Beziehen Sie Repository-, Organisations- und Enterprise-Runner in die Erhebung ein. Ein nur lokal gepflegtes Verzeichnis reicht nicht, wenn Teams Knoten in unterschiedlichen Bereichen registrieren. Die GitHub-Verwaltungsanleitung für selbstgehostete macOS-Runner hilft dabei, die Verwaltungs- und Konfigurationsstellen zu prüfen.

Dokumentieren Sie auch, ob automatische Updates deaktiviert wurden. Bei einer verwalteten Flotte kann die Einstellung an einem einzelnen Knoten, aber ebenso in einem Image oder in der Erstellungsautomatisierung festgelegt sein. Ergänzen Sie im Inventar deshalb die Quelle der Runner-Software und nicht nur den Zustand der laufenden Maschine.

Rufen Sie für die betroffene Runner-Version die offizielle Deprecation-API ab und gleichen Sie das Ergebnis mit Ihrer Bestandsliste ab. Lesen Sie die Antwort anhand der API-Dokumentation: relevant sind der Status für Registrierung beziehungsweise erneute Registrierung und die Laufzeitunterstützung samt angegebener Fristen. Verwenden Sie nicht bloß die Installationsversion als Ersatz für diese Prüfung. Die REST-API zur Außerdienststellung von Runner-Versionen ist die maßgebliche Quelle für die aktuelle versionsbezogene Auskunft.

Gehen Sie in einer nachvollziehbaren Reihenfolge vor:

1. Umgebung festhalten. Notieren Sie, ob der Runner zu GitHub Enterprise Cloud, zur Variante mit Datenresidenz oder zu GitHub Enterprise Server gehört.
2. Version erfassen. Lesen Sie die installierte Runner-Version direkt am Knoten oder aus dem zentralen Konfigurationsbestand aus; übernehmen Sie den Wert nicht aus einer Image-Bezeichnung, ohne ihn zu verifizieren.
3. API-Status abfragen. Prüfen Sie, ob die Version registriert werden darf und ob sie noch zur Ausführung von Workflows unterstützt wird. Notieren Sie Abfragezeitpunkt und Ergebnis.
4. Knoten zuordnen. Verknüpfen Sie den API-Status mit Verwaltungsbereich, Online-Status, Bereitstellungsweg und Arbeitslast des jeweiligen Runners.
5. Handlungsbedarf markieren. Priorisieren Sie Knoten, die nicht mehr registriert werden dürfen, deren Laufzeitunterstützung endet oder deren Version aus einem veralteten Image erzeugt wird.

Der letzte Punkt ist wichtig, weil bestehende Registrierung und künftiger Ersatz unterschiedliche Betriebsfälle sind. Ein Runner kann heute noch erreichbar sein, während ein neu aufgesetzter Ersatzknoten an der Registrierung scheitert. Umgekehrt kann die Registrierung funktionieren, obwohl die installierte Laufzeitversion bereits gegen eine aktuelle Ausführungsgrenze geprüft werden muss. Halten Sie diese Fälle getrennt, damit der Bereitschaftsstatus keine falsche Sicherheit vermittelt.

Wählen Sie das Verfahren abhängig davon, wie die Runner bereitgestellt werden. Automatische Updates verringern den manuellen Pflegebedarf, setzen aber voraus, dass die Knoten den Aktualisierungsdienst erreichen können. Bei deaktivierten automatischen Updates trägt das Team die Verantwortung für regelmäßige Pflege, kontrollierte Bereitstellung und ein geprüftes Rückfallverfahren. Die Regeln zur automatischen Aktualisierung sind in der offiziellen Runner-Dokumentation beschrieben.

Aktualisieren Sie nicht die gesamte Produktionsflotte in einem ungetesteten Schritt. Beginnen Sie mit einem nicht kritischen Knoten, der für die gleiche macOS-Arbeitslast und denselben Bereitstellungsweg steht wie die produktive Gruppe. Prüfen Sie, ob der Knoten nach der Aktualisierung registriert bleibt, seine Warteschlange erreicht und Aufträge annimmt. Erst wenn dieser Test bestanden ist, rollen Sie den aktualisierten Stand auf weitere Knoten aus.

Bei Images und automatisierter Bereitstellung genügt es nicht, den Runner auf einer bereits laufenden Maschine zu aktualisieren. Passen Sie auch die Vorlage an, aus der Ersatzknoten erstellt werden. Prüfen Sie Installationsskripte, Build-Caches und Container-Definitionen auf fest eingetragene alte Versionen. Halten Sie das zuvor freigegebene Artefakt als Rückfall bereit; kennzeichnen Sie dabei eindeutig, ob es für die Registrierung und den aktuellen Laufzeitstatus noch zulässig ist.

Kann ein Runner noch online sein, obwohl er keine Aufträge mehr ausführt?
Ja. Online-Status allein beweist weder die aktuelle Laufzeitunterstützung noch die Verfügbarkeit für die richtige Warteschlange. Prüfen Sie Version, Verwaltungsbereich und Auftragsannahme getrennt und führen Sie einen realen Workflow aus.

Ist 2.329.0 die gemeinsame Mindestversion für Registrierung und Ausführung?
Nein. Diese Versionsschwelle betrifft die Registrierung beziehungsweise erneute Registrierung im betroffenen GitHub Enterprise Cloud. Für die Ausführung gilt eine dynamische Unterstützung, deren Status über die offizielle Deprecation-API kontrolliert werden muss.

Was ist bei deaktivierter automatischer Aktualisierung erforderlich?
Ein dokumentierter Wartungsprozess mit zuständiger Rolle, geprüfter Aktualisierung, Rückfallartefakt und Prüfung der Images sowie Installationsautomatisierung. Ohne diese Kontrollen kann ein später neu erzeugter Runner wieder eine veraltete Softwareversion erhalten.

Wie lässt sich die Außerdienststellung einer Version feststellen?
Rufen Sie die offizielle Runner-Versionen-Deprecation-API ab, lesen Sie die Angaben zu Registrierung und Laufzeit und ordnen Sie die Antwort der konkreten Runner-Version im Inventar zu. Protokollieren Sie das Ergebnis mit Abfragezeitpunkt.

Eine erfolgreiche Installation ist erst der Anfang der Abnahme. Der aktualisierte Mac CI Runner muss die produktive Arbeitslast ausführen können, für die er vorgesehen ist. Verifizieren Sie die Kette aus Registrierung, Warteschlange, Toolchain und Ergebnis anhand eines Workflow-Laufs, der dem tatsächlichen Einsatz entspricht.

1. Auftragsannahme prüfen. Starten Sie einen Workflow, der den aktualisierten Runner über die vorgesehene Zuordnung auswählt. Bestätigen Sie, dass er den Auftrag tatsächlich übernimmt und nicht lediglich in der Warteschlange verbleibt.
2. Toolchain kontrollieren. Prüfen Sie, ob die für das Projekt festgelegten Werkzeuge und Laufzeitkomponenten auf dem Knoten verfügbar sind. Dokumentieren Sie relevante Abweichungen zur freigegebenen Basis.
3. Build und Tests ausführen. Verwenden Sie einen repräsentativen iOS- oder macOS-Build mit den zugehörigen Tests. Ein Testlauf, der den kritischen Pipeline-Schritt auslässt, weist die Produktionsfähigkeit nicht nach.
4. Signierung und Veröffentlichung gesondert prüfen. Wenn der Knoten Aufgaben mit Signaturmaterial oder Release-Berechtigungen übernimmt, testen Sie den tatsächlichen Ende-zu-Ende-Ablauf mit den vorgesehenen Berechtigungen. Eine erfolgreiche Kompilierung beweist nicht, dass ein Release-Auftrag funktioniert.
5. Nachweise sichern. Halten Sie Runner-Version, Workflow-Ergebnis, Fehlerprotokolle, Freigabe und mögliche Rückfallentscheidung fest. So lässt sich bei späteren Problemen nachvollziehen, welcher Stand tatsächlich abgenommen wurde.

Verwenden Sie zur Eingrenzung von Fehlern die GitHub-Anleitung für Überwachung und Fehlerbehebung selbstgehosteter Runner. Unterscheiden Sie dabei Versionsfehler von Netzwerkproblemen, falscher Warteschlangenzuordnung, fehlender Toolchain und Berechtigungsproblemen. Andernfalls wird ein Update zurückgerollt, obwohl die eigentliche Ursache an anderer Stelle liegt.

Legen Sie vor dem Rollout fest, wann ein Rückfall ausgelöst wird. Beispiele sind eine fehlgeschlagene Registrierung, ausbleibende Auftragsannahme, reproduzierbare Fehler in einem kritischen Build oder ein nicht funktionsfähiger Signatur- und Release-Schritt. Ein Rückfall ist keine dauerhafte Ausnahme von der Versionspflege: Nach der Stabilisierung braucht es einen neuen, dokumentierten Aktualisierungspfad.

Ein einmalig reparierter Runner-Bestand bleibt nur dann belastbar, wenn die Versionsprüfung wiederkehrend erfolgt. Nehmen Sie die API-Abfrage in den Wartungsprozess auf und gleichen Sie das Ergebnis mit dem Inventar ab. Da GitHub die Laufzeitunterstützung weiterentwickeln kann, sollte der Prozess nicht auf einer in der Dokumentation oder in einem Ticket festgeschriebenen Versionsnummer stehen bleiben.

Erzeugen Sie eine Meldung, wenn eine installierte Version nicht mehr registriert werden darf, ihre Laufzeitunterstützung endet oder die API-Abfrage nicht zuverlässig abgeschlossen werden kann. Eine fehlende API-Antwort ist kein Beleg für einen unveränderten Status. Weisen Sie für automatische Updates, manuelle Pflege und Image-Änderungen jeweils eine verantwortliche Rolle zu und legen Sie fest, wer bei einer gestörten Warteschlange die Eskalation übernimmt.

Die GitHub-Verwaltungsanleitung für selbstgehostete Runner und die Dokumentation zur Überwachung und Fehlerbehebung sollten Teil des Betriebsverfahrens sein. Ergänzen Sie dort interne Nachweise: Zeitpunkt der Versionsabfrage, betroffene Runner, genehmigter Rollout, Abnahme-Workflow und Entscheidung über Rückfall oder Freigabe. So können Plattform- und IT-Teams denselben Status verwenden, ohne die Ursache nur aus einer Fehlermeldung rekonstruieren zu müssen.

Für die Beschaffung zusätzlicher Kapazität gehören außerdem Datenschutz, Zugang und vertragliche Bedingungen in die Prüfung. Verknüpfen Sie diese Fragen mit den eigenen Sicherheitsvorgaben und prüfen Sie bei einem extern bereitgestellten Mac die konkreten Leistungs- und Vertragsdetails, statt sie aus einer allgemeinen Produktbeschreibung abzuleiten. Die NUKCLOUD-Nutzungsbedingungen sind dafür ein zusätzlicher Prüfpunkt, ersetzen aber keine interne Sicherheitsfreigabe.

Eine eigene Mac-Flotte bietet direkte Kontrolle über Hardware, Netzwerkanbindung und physische Schnittstellen; sie ist besonders plausibel, wenn die Knoten dauerhaft ausgelastet sind oder besondere Geräteverbindungen benötigen. Dafür muss das Unternehmen Beschaffung, Ersatzgeräte, Aktualisierungen, Images und den Bereitschaftsbetrieb selbst organisieren. Eine temporäre Erweiterung durch entfernte Macs kann dagegen sinnvoll sein, wenn ein Team während eines Upgrades zusätzliche Build-Kapazität benötigt oder die Anschaffung von Reservegeräten vermeiden will. Sie ersetzt keine eigene Sicherheitsprüfung und ist nicht automatisch die bessere Wahl für dauerhaft intensive Lasten.

Wenn die Flotte während der Versionsbereinigung knapp wird, sollte die Entscheidung daher vom Engpass ausgehen: Bei kurzfristigem Bedarf kann ein zeitlich begrenzter entfernter Mac als zusätzliche Kapazität geprüft werden; bei dauerhafter Auslastung, besonderen physischen Schnittstellen oder strikten internen Betriebsauflagen kann ein eigener Knotenpool geeigneter sein. NUKCLOUD bietet den Zugang zu einem realen Mac über Remote-Verbindungen; prüfen Sie vor dem Einsatz, ob Zugriff, Netzwerkweg und Ihre Freigabeprozesse zur CI-Aufgabe passen. Einen Einstieg in die verfügbaren Remote-Mac-Optionen finden Sie auf der NUKCLOUD-Übersichtsseite.

Unabhängig davon, ob zusätzliche Knoten selbst betrieben oder zeitweise gemietet werden: Aktualisieren Sie den Runner-Stand, prüfen Sie die API-Fristen und nehmen Sie jede relevante Pipeline mit einem echten Auftrag ab. Nur diese Kombination trennt einen bloß erreichbaren Mac von einem Runner, der für den vorgesehenen iOS-CI/CD-Betrieb tatsächlich freigegeben ist.