Prüfen Sie zuerst, ob eine JavaScript Action an der GitHub-Actions-Runtime scheitert oder ob Ihr Projekt seine eigene Node.js-Version nicht starten kann. Aktualisieren Sie eine betroffene Action auf eine Node-24-kompatible Version und testen Sie sie isoliert; prüfen Sie bei selbst gehosteten Mac Runnern zusätzlich macOS-Version und Prozessorarchitektur.

Das gilt für Sie, wenn Sie als IT-Verantwortliche oder IT-Verantwortlicher den Einfluss auf Mac-CI und die Wiederherstellungspriorität ermitteln müssen.
Es richtet sich außerdem an Plattformteams, die Runner, Actions oder Organisationsvorlagen pflegen, sowie an iOS- und macOS-Verantwortliche, die Builds vor der Freigabe belastbar abnehmen wollen.

Zeitplan und Wochenaktion: GitHub meldet, dass Node 20 am 23.09.2026 aus der GitHub-Actions-Runner-Umgebung entfernt und durch Node 24 ersetzt wurde. Prüfen Sie in dieser Woche zuerst die Actions Ihrer wichtigsten Workflows, bevor Sie Runner austauschen oder zusätzliche Mac-Kapazität beschaffen. GitHubs Änderungsmitteilung zum Ende von Node 20

Zuletzt aktualisiert am 21.10.2026; abgeglichen mit der GitHub-Mitteilung zum Laufzeitwechsel und der Dokumentation zu Action-Metadaten.

01

Fehlersignale nach Runtime, Action und Runner trennen

Der Ausdruck „Node 20“ kann in einem CI-Protokoll unterschiedliche Ebenen bezeichnen. Für die Diagnose zählt, welcher Prozess den Fehler ausgibt und an welcher Stelle der Job anhält.

Die GitHub-Actions-Runtime führt JavaScript Actions aus. Eine Action deklariert ihre Runtime in den Metadaten. Das ist nicht dasselbe wie Node.js, das Ihr Workflow für Anwendungsskripte installiert oder aufruft. GitHub beschreibt das Installieren und Verwenden von Node.js in einem Projekt-Workflow gesondert in seinem Node.js-Workflow-Tutorial.

Ordnen Sie das Protokoll diesen Indikatoren zu:

  • Fehler vor dem eigentlichen Projektbefehl: Der Job scheitert beim Laden, Initialisieren oder Ausführen einer Action. Prüfen Sie deren Version und Runtime-Deklaration.
  • Fehler in einem Node.js-Setup-Schritt: Der Workflow hat möglicherweise Probleme mit seiner Installationsaktion, Eingabe oder Versionsauswahl. Untersuchen Sie diesen Schritt, ohne sofort die Runner-Runtime mit der Projektversion gleichzusetzen.
  • Fehler nach erfolgreichem Action-Start: Scheitert erst npm install, ein Test oder ein Build, untersuchen Sie Projektabhängigkeiten, Skripte und die ausdrücklich eingerichtete Node.js-Version.
  • Fehler nur auf einem selbst gehosteten Mac: Prüfen Sie zusätzlich das Betriebssystem und die Architektur. Ein identischer Workflow auf einem anderen Runner kann den Unterschied sichtbar machen, beweist aber allein noch keine Ursache.

Ein plausibler Fall: Ein iOS-Workflow startet erfolgreich, bleibt dann beim Einrichten eines Artefaktschritts stehen und erreicht den Xcode-Build nicht. In dieser Situation sollten Sie zunächst die aufgerufene Action untersuchen. Die Node.js-Version einer Web-Komponente im Repository zu ändern wäre kein zielgerichteter erster Schritt.

02

Action-Versionen und Runtime-Angaben inventarisieren

Ein Workflow kann Actions direkt aufrufen, über eine zusammengesetzte Action einbinden oder gemeinsame Vorlagen aus der Organisation verwenden. Wenn Sie nur die sichtbare Workflow-Datei prüfen, können indirekte Abhängigkeiten unentdeckt bleiben.

Gehen Sie bei der Bestandsaufnahme in dieser Reihenfolge vor:

  1. Suchen Sie in den produktiven Workflow-Dateien nach allen direkten uses:-Angaben. Halten Sie Action-Name und referenzierte Version fest.
  2. Öffnen Sie die referenzierten Composite Actions und prüfen Sie auch dort die enthaltenen Action-Aufrufe. Eine Wrapper-Action kann den tatsächlichen JavaScript-Aufruf verbergen.
  3. Beziehen Sie Organisationsvorlagen und wiederverwendbare Workflows ein. Dokumentieren Sie, welche Teams dieselbe Vorlage verwenden und ob ein Update mehrere Pipelines betrifft.
  4. Prüfen Sie bei selbst gepflegten JavaScript Actions die Metadaten. Das Feld runs.using gibt an, welche Node-Runtime die Action deklariert. GitHub erklärt Syntax und Bedeutung in der Referenz zu Metadaten für Workflows und Actions.
  5. Gleichen Sie die Deklaration mit dem tatsächlichen Workflow-Aufruf ab. Eine aktualisierte Action im Repository hilft nicht, wenn der produktive Workflow weiterhin eine ältere Referenz nutzt.

Erstellen Sie daraus keine bloße Liste veralteter Versionen. Ergänzen Sie, welche Builds die jeweilige Action verwenden, welche Teams dafür verantwortlich sind und ob sie sicher einzeln aktualisiert werden kann. So erkennen Sie, ob der Fehler auf einen einzelnen Testjob begrenzt ist oder eine zentrale Vorlage betrifft.

Eine Runner-Anzeige „online“ belegt nur, dass der Runner erreichbar ist. Sie sagt nicht aus, ob eine JavaScript Action initialisiert, ein Xcode-Build abgeschlossen oder ein Release-Artefakt korrekt erstellt wurde.

03

Kompatibilität des selbst gehosteten Mac Runners bewerten

Neben der Action-Version ist die Systemumgebung ein eigener Prüfpunkt. GitHub weist darauf hin, dass Node 24 mit macOS 13.4 und früheren Versionen nicht kompatibel ist. ARM32 wird ebenfalls nicht offiziell unterstützt. Die Änderungsmitteilung zum Node-24-Wechsel nennt diese Einschränkungen ausdrücklich.

Prüfen Sie deshalb für den betroffenen Runner die tatsächlich installierte macOS-Version und die gemeldete Prozessorarchitektur. Verlassen Sie sich nicht auf einen Rechnernamen, eine Einkaufsbezeichnung oder die Annahme, dass alle Mac-Systeme dieselbe Architektur melden. Die Angaben müssen zu dem Runner passen, auf dem der fehlgeschlagene Job ausgeführt wurde.

Für die Kompatibilität eines macOS-13.4-Runners ist die konkrete Grenze wichtig: macOS 13.4 und frühere Versionen fallen laut GitHub unter die Einschränkung. Daraus folgt nicht, dass jeder selbst gehostete Mac Runner oder jedes Apple-Silicon-System betroffen ist. Insbesondere darf die ARM32-Angabe nicht pauschal mit Apple Silicon gleichgesetzt werden. Prüfen Sie den tatsächlichen Architekturwert des Systems.

Für die Zuordnung zum Runner kontrollieren Sie die Labels und Auswahlregeln des Jobs. GitHub beschreibt, wie ein Workflow über seine Runner-Auswahl einem passenden Runner zugeordnet wird, in der Dokumentation zur Auswahl eines Runners für einen Job. Die Dokumentation zu selbst gehosteten Runnern hilft außerdem dabei, die eigene Runner-Umgebung als Betriebskomponente einzuordnen.

Die Diagnose sollte mindestens diese Merkmale zusammenführen: Jobname, Workflow-Referenz, aufgerufene Action-Version, macOS-Version, Architektur und Fehlerstelle im Protokoll. Ohne diese Zuordnung riskieren Sie, eine nicht betroffene Maschine zu verändern und den eigentlichen inkompatiblen Action-Aufruf bestehen zu lassen.

04

Node-20-Fehler mit einem reproduzierbaren Prüfablauf eingrenzen

Arbeiten Sie vom beobachteten Fehler zur kleinsten plausiblen Ursache. Verändern Sie nicht gleichzeitig Action-Version, macOS-Umgebung und Projektkonfiguration. Sonst lässt sich nicht mehr sauber erkennen, welche Änderung den Job beeinflusst hat.

  1. Fehlgeschlagenen Job sichern. Speichern Sie den vollständigen relevanten Protokollabschnitt und notieren Sie Workflow, Job, Commit und Runner-Zuordnung. Ein Ausschnitt nur mit der letzten Fehlermeldung kann den vorausgehenden Initialisierungsfehler auslassen.
  2. Fehlerphase bestimmen. Entscheiden Sie, ob die Action beim Start scheitert, eine Abhängigkeit fehlt oder erst ein Projektbefehl fehlschlägt. Vergleichen Sie den Zeitpunkt mit den Schritten im Workflow.
  3. Action-Aufruf nachverfolgen. Prüfen Sie direkte und indirekte uses:-Referenzen sowie die verwendete Version. Bei einem eigenen Action-Repository kontrollieren Sie runs.using in der Metadatendatei.
  4. Runner-Merkmale erfassen. Lesen Sie macOS-Version und Architektur aus der konkreten Runner-Umgebung aus. Verknüpfen Sie diese Werte mit dem Job, statt allgemeine Angaben zur Hardware zu übernehmen.
  5. Kandidat isoliert testen. Aktualisieren Sie eine betroffene Action-Version in einem separaten Workflow oder auf einem nicht kritischen Pfad. Verwenden Sie repräsentative Eingaben und prüfen Sie Ausgaben sowie Fehlerbehandlung.
  6. Den vollständigen Zieljob ausführen. Lassen Sie denselben Workflow die relevanten Action-Initialisierungen, Abhängigkeitsinstallationen und tatsächlichen Xcode-Build- oder Testschritte durchlaufen. Ein einzelner erfolgreicher Setup-Schritt ist keine Abnahme.
  7. Ergebnis dokumentieren. Halten Sie die getestete Action-Referenz, macOS-Version, Architektur und den Status der entscheidenden Aufgaben fest. So können Sie den Produktivlauf mit dem isolierten Test vergleichen.

Wenn die Fehlerstelle unklar bleibt, erstellen Sie einen kleinen Workflow, der denselben Action-Aufruf und dieselbe Runner-Auswahl verwendet, aber keine Veröffentlichung auslöst. Ändern Sie jeweils nur eine Variable. So können Sie beispielsweise die Action-Version prüfen, ohne zugleich den produktiven Signierungs- oder Release-Pfad anzutasten.

05

Reparatur nach Belegen auswählen

Aktualisieren Sie zuerst die Action, wenn der Fehler auf eine alte oder inkompatible JavaScript Action zurückführt und eine gepflegte Version mit Node-24-Unterstützung verfügbar ist. Testen Sie diese Version getrennt, bevor Sie die Referenz in kritischen Workflows übernehmen. Beachten Sie dabei, dass ein Versionswechsel auch Eingaben, Ausgaben und Fehlerbehandlung beeinflussen kann; prüfen Sie diese Schnittstellen im Workflow.

Wenn Sie die Action selbst pflegen, liegt die Änderung bei Ihrem verantwortlichen Team: Runtime-Deklaration und Implementierung müssen zur neuen Ausführungsumgebung passen. Veröffentlichen Sie erst nach einem Test eine aktualisierte Version und dokumentieren Sie, welche Workflows sie übernehmen sollen. Ändern Sie nicht nur den Metadatenwert, ohne die Action tatsächlich mit der deklarierten Runtime zu prüfen.

Ändern Sie die Runner-Umgebung erst dann, wenn die vorliegenden Angaben auf eine System- oder Architekturgrenze zeigen. GitHub dokumentiert die Workflow-Syntax einschließlich der Runner-Auswahl; nutzen Sie diese Auswahlregeln, um einen kontrollierten Test auf einer geeigneten Umgebung zu ermöglichen. Ein Wechsel des Mac ist keine Standardmaßnahme gegen jeden Node-20-Fehler.

Entscheidungshilfe:

  • [ ] Action-Laufzeit bestätigt: Der Fehler tritt beim Laden oder Initialisieren einer JavaScript Action auf. Aktualisieren Sie auf eine Version mit Node-24-Unterstützung und testen Sie sie isoliert. Wenn keine gepflegte Version existiert, klären Sie die Wartungsverantwortung oder prüfen Sie eine Alternative.
  • [ ] Betriebssystemgrenze bestätigt: Der betroffene Runner verwendet macOS 13.4 oder früher. Prüfen Sie eine unterstützte Systemumgebung, aber ändern Sie den Runner erst, wenn der Fehler auf dieser Grenze beruht.
  • [ ] Projektbefehl ist die Fehlerstelle: Die Action läuft, aber ein Projektbefehl wie Installation, Test oder Build schlägt fehl. Prüfen Sie die projektseitige Node.js-Version, Abhängigkeiten und Skripte, statt die Action-Runtime als Ursache festzulegen.
  • [ ] Vollständiger kritischer Job bestanden: Action-Initialisierung, Build und relevante Tests laufen auf der vorgesehenen Umgebung durch. Geben Sie den Workflow nach Ihren Release-Kriterien frei. Andernfalls bleibt er isoliert oder die Freigabe wird zurückgestellt.

Wenn mehrere Punkte zutreffen, behandeln Sie die Ursachen getrennt. Ein Betriebssystemwechsel behebt nicht automatisch eine Action, die ihre Runtime falsch deklariert; ein Action-Update behebt umgekehrt keine inkompatible Systemumgebung.

06

Freigabe an echten Build- und Testergebnissen festmachen

Die Abnahme muss dieselben entscheidenden Arbeitsschritte abdecken wie der produktive Workflow. Für iOS- und macOS-Teams bedeutet das mindestens, dass der Job nicht nur den Runner erreicht, sondern die für den konkreten Release erforderlichen Action-Aufrufe und Build- oder Testschritte tatsächlich abschließt. Ein grüner Nebenjob ersetzt keine Prüfung des kritischen Veröffentlichungswegs.

Legen Sie vor dem Rollout fest, welche Beobachtung zur Freigabe führt. Dazu gehören der verwendete Action-Stand, die Runner-Umgebung, der Status der relevanten Build- und Testschritte sowie nachvollziehbare Fehlerprotokolle. Bei einem Fehlschlag behalten Sie den getesteten Pfad isoliert und setzen die produktive Referenz nicht auf Verdacht um.

Freigeben können Sie, wenn die betroffenen Actions unter der vorgesehenen Runner-Umgebung initialisieren und die entscheidenden Aufgaben desselben Workflows bestehen. Zurückstellen sollten Sie, wenn die Action zwar lädt, aber Build, Test oder Fehlerbehandlung nicht verifiziert sind. Isoliert weiterprüfen ist sinnvoll, wenn der Fehler nicht zuverlässig reproduzierbar ist oder sich Runner- und Action-Ursache noch nicht trennen lassen.

Vermerken Sie außerdem, wer künftig Action-Versionen, Organisationsvorlagen und macOS-Kompatibilität überwacht. Vereinbaren Sie eine erneute Prüfung, wenn GitHub seine Runtime-Vorgaben ändert, eine zentrale Action aktualisiert wird oder ein Runner auf eine andere Systemversion wechselt. Die offizielle Dokumentation zu selbst gehosteten Runnern bietet dafür den passenden Ausgangspunkt zur Verwaltung der Runner-Seite.

Für Unternehmen mit mehreren CI-Pfaden hilft eine klare Trennung zwischen GitHub-Actions-Fehler und Mac-Infrastrukturproblem. Dokumentieren Sie zuerst, welche Jobs einen Mac benötigen und welche Anforderungen an Systemversion, Architektur und Zugriff gelten. Wenn Sie Remote-Mac-Optionen als ergänzende Kapazität prüfen, vergleichen Sie die tatsächlich beschriebenen Umgebungs- und Bereitstellungsmerkmale, nicht vermutete Leistungs- oder Verfügbarkeitswerte. Eine Übersicht zu Mac-Mietpreisen und verfügbaren Optionen kann als Einstieg in diese Prüfung dienen. Wenn Sie anschließend eine konkrete Mietoption prüfen möchten, finden Sie auch Informationen zum Bestellen eines Mac mini M4; gleichen Sie die dortigen Angaben mit den Anforderungen Ihres Workflows ab, bevor Sie einen produktiven Job verlagern.

07

Häufige Fragen zur Mac-CI-Fehlerdiagnose

Warum scheitert Mac-CI nach dem Ende der Node-20-Laufzeit?

GitHub hat Node 20 als JavaScript-Action-Runtime aus der Runner-Umgebung entfernt und Node 24 eingesetzt. Eine Action kann deshalb schon vor dem eigentlichen Build scheitern, wenn sie mit der neuen Runtime nicht zurechtkommt. Das allein beweist jedoch nicht, dass Ihre projektseitig installierte Node.js-Version geändert oder entfernt wurde. Prüfen Sie die Fehlerstelle und die Metadaten der aufgerufenen Action.

Wie erkennen Sie, ob eine Action oder Ihr Projekt-Node.js betroffen ist?

Prüfen Sie zunächst, welcher Workflow-Schritt unmittelbar vor dem Fehler ausgeführt wurde. Ein Fehler beim Laden oder Initialisieren einer JavaScript Action deutet auf deren Runtime beziehungsweise Kompatibilität. Scheitert dagegen ein Projektbefehl nach einem Node.js-Setup-Schritt, untersuchen Sie die Projektversion, Abhängigkeiten und Skripte. Vergleichen Sie den tatsächlichen Action-Aufruf mit dem Feld runs.using in den Metadaten.

Wie aktualisieren Sie eine ältere JavaScript Action auf Node 24?

Ermitteln Sie die Version, die der produktive Workflow tatsächlich referenziert, und suchen Sie eine gepflegte Version, die Node 24 unterstützt. Testen Sie diese Referenz isoliert mit denselben Eingaben und prüfen Sie Ausgaben sowie Fehlerpfade. Bei einer eigenen Action aktualisieren Sie Implementierung und Metadaten gemeinsam, lassen die Änderung testen und veröffentlichen erst danach eine Version für die Workflows.

Kann die macOS-Version einen selbst gehosteten Mac Runner blockieren?

Ja, die offizielle Kompatibilitätsgrenze nennt macOS 13.4 und frühere Versionen als nicht mit Node 24 kompatibel. Prüfen Sie die Version auf dem Runner, der den Fehler erzeugt hat, und lesen Sie dessen Architektur separat aus. Die Einschränkung bedeutet nicht, dass alle Macs betroffen sind. Eine Architekturangabe wie ARM32 darf auch nicht pauschal auf Apple-Silicon-Systeme übertragen werden.

Wenn Ihre kritischen Builds nach der Korrektur weiterhin eine passende macOS-Umgebung benötigen, entscheiden Sie anhand der Workload-, Sicherheits- und Kompatibilitätsanforderungen, ob vorhandene Hardware genügt oder zusätzliche Remote-Mac-Kapazität geprüft werden sollte. Bleiben Sie bei Kauf, lokalem Betrieb oder einem anderen CI-Aufbau, wenn Sie dauerhafte physische Kontrolle oder besondere Schnittstellen benötigen. Wenn Sie eine zeitlich begrenzte Mac-Umgebung evaluieren, prüfen Sie die konkreten Liefer- und Umgebungsangaben von VpsMesh, bevor Sie einen produktiven Workflow dorthin verlagern.