GitHub Actions macOS 14 Runner vor dem Ruhestand: Wie finden Sie alle Alt-Workflows? Checkliste 2026

GitHub hat die Außerbetriebnahme der macOS-14-Runner-Images für den 02.11.2026 angekündigt; betroffen sind macos-14, macos-14-large und macos-14-xlarge (offizielle Ankündigung).

Symptom: Eine Suche im Standardzweig findet keine Treffer, aber Sie wissen nicht, ob wirklich alle Builds erfasst sind.
Schnellste belastbare Lösung: Erfassen Sie Organisation, Repositories, wiederverwendbare Workflows und tatsächliche Läufe gemeinsam; ändern Sie Labels erst, wenn die betroffenen Workloads zugeordnet sind.

Dieser Leitfaden ist für Sie, wenn Sie GitHub-Organisationen verwalten und alte Runner-Labels über mehrere Repositories hinweg finden müssen.
Er richtet sich außerdem an CI-Plattformverantwortliche, die dynamische Konfigurationen und reale Läufe abgleichen.
Wenn Sie Build-, Test- oder Release-Pipelines verantworten, finden Sie hier Kriterien für die nachvollziehbare Migrationsabnahme.

Zuletzt aktualisiert am 08.10.2026. Die Angaben zu Abschalttermin, betroffenen Labels, Brownout-Planung und Ersatz-Labels sind anhand der GitHub-Mitteilung geprüft. Vor der Umsetzung sollten Sie diese Mitteilung und die offiziellen Runner-Informationen erneut kontrollieren.

Was gilt als vollständiger Bestand veralteter Labels?

Eine Trefferliste aus einer Textsuche ist noch kein Nachweis, dass Ihre Organisation vollständig geprüft wurde. Für eine belastbare Bestandsaufnahme müssen Sie zeigen können, welche Repositories zum Suchumfang gehören, welche Konfigurationsquellen einbezogen wurden und wie Sie statische Funde mit tatsächlichen Läufen abgeglichen haben.

Die GitHub Actions macOS 14 Runner-Abschaltung betrifft die angekündigten gehosteten Runner-Images und Labels. Leiten Sie daraus nicht ab, dass selbst gehostete Macs denselben Abschaltstatus hätten: Prüfen Sie deren Betrieb und Support getrennt. Auch in Ihrer eigenen Bestandsaufnahme sollten gehostete Labels und selbst verwaltete Runner daher als verschiedene Kategorien erscheinen.

Legen Sie zuerst den Umfang fest. Dazu gehören aktive Repositories, gepflegte Projekte mit seltenen Releases und Repositories, deren Workflows über zentrale Vorlagen oder wiederverwendbare Workflows eingebunden werden. Klären Sie mit den Repository-Verantwortlichen, wie Sie archivierte Projekte, Forks, private Repositories und nicht zugängliche Bereiche behandeln. Ein ausgeschlossener Bereich ist kein „bereinigter“ Bereich: Er muss mit Begründung, Verantwortlichem und offenem Risiko dokumentiert werden.

Prüfen Sie die exakten Labels macos-14, macos-14-large und macos-14-xlarge; GitHub nennt diese als betroffen in der Ankündigung zur Runner-Abschaltung. Suchen Sie zusätzlich nach Konfigurationen, die diese Zeichenfolgen zusammensetzen, etwa über Matrix-Werte oder Eingabeparameter. Der Workflow-Syntaxreferenz zufolge können Jobs unter anderem mit runs-on einem Runner zugeordnet werden. Die relevante Stelle muss daher nicht zwingend als einfacher, ausgeschriebener Text im Job erscheinen.

Checkliste: Ist Ihre Abdeckung nachweisbar?

Nutzen Sie die folgende Liste als Arbeitsnachweis und nicht bloß als einmalige Suchanfrage. Weisen Sie jedem Punkt eine zuständige Person zu und halten Sie Fundstellen mit Repository-Pfad und Workflow-Namen fest.

• [ ] Organisationsumfang festgehalten: Sie haben dokumentiert, welche Organisationen und Repositories geprüft werden und welche Bereiche nicht einbezogen werden. Für fehlende Zugriffsrechte, archivierte Projekte und genehmigte Ausnahmen ist ein Grund vermerkt.
• [ ] Zweige und Pflegezustand bewertet: Sie haben geprüft, ob relevante Workflows nur in anderen aktiven Zweigen oder in selten genutzten, aber weiterhin gepflegten Projekten liegen. Eine Suche ausschließlich im Standardzweig gilt nicht als organisationsweite Prüfung.
• [ ] Alle betroffenen Labels gesucht: Die Suche umfasst macos-14, macos-14-large und macos-14-xlarge. Sie ist nicht auf die wörtliche Form im einzelnen runs-on-Feld beschränkt.
• [ ] Wiederverwendung verfolgt: Sie haben sowohl wiederverwendbare Workflows als auch deren Aufrufer geprüft. Zu jedem Fund ist klar, ob das Label im aufrufenden Workflow, als Eingabewert oder im wiederverwendeten Workflow festgelegt wird.
• [ ] Dynamische Werte untersucht: Matrizen, Ausdrücke, Variablen und generierte Workflow-Dateien sind in den Suchumfang aufgenommen oder ausdrücklich als nicht verwendete Konfigurationswege begründet.
• [ ] Reale Läufe abgeglichen: Sie haben statische Treffer mit den tatsächlichen Ausführungen verglichen und festgehalten, wann ein Workflow zuletzt nachvollziehbar lief, durch welches Ereignis er ausgelöst wurde und welches Runner-Label dabei verwendet wurde.
• [ ] Jeder Fund hat einen Status: Für jeden betroffenen Workflow sind Verantwortlicher, Kritikalität, Ziel-Label, Testergebnis und offene Blockaden erfasst. „Keine kürzlichen Fehler“ ist kein Beleg dafür, dass keine Abschaltungsabhängigkeit besteht.
• [ ] Nicht erreichbare Fälle sichtbar gemacht: Repositories oder Workflows, deren Laufhistorie oder Konfiguration nicht geprüft werden konnte, bleiben als offene Punkte in der Liste und werden nicht stillschweigend als erledigt gezählt.

Als zentrale Evidenzliste empfiehlt sich pro Fund eine nachvollziehbare Zeile mit Repository, Pfad, Workflow-Name, Fundstelle des Labels, Quelle des Werts, Auslöser, letzter verfügbarer Lauf, Aufgabenart, Verantwortlichem und Abnahmestatus. Diese Felder verhindern, dass ein Treffer zwar entfernt wird, aber der zugehörige Aufrufer oder die tatsächliche Release-Aufgabe übersehen bleibt.

Versteckte Runner-Abhängigkeiten in der Konfiguration

Die schwierigsten Funde sind häufig keine offensichtlichen Zeilen wie runs-on: macos-14. Eine Workflow-Datei kann einen wiederverwendbaren Workflow aufrufen, der seinerseits den Runner bestimmt. Ebenso kann ein Eingabewert aus dem aufrufenden Workflow kommen, bevor er in einer Matrix oder einem Ausdruck ausgewertet wird.

Behandeln Sie deshalb den Konfigurationsweg als Kette: Quelle des Werts → Übergabe → Auswertung → Runner-Zuweisung. Der Leitfaden zu wiederverwendbaren Workflows beschreibt die Beziehungen zwischen aufrufendem und wiederverwendetem Workflow. Die Dokumentation zu Kontexten und die Referenz zu Ausdrücken helfen dabei, Werte zu identifizieren, die erst zur Laufzeit eingesetzt oder ausgewertet werden.

Für jede Konfigurationsquelle sollten Sie festhalten, wo sie definiert wird und an welcher Stelle sie tatsächlich verbraucht wird. Suchen Sie beispielsweise nach einem Runner-Label in einer zentralen Vorlage und verfolgen Sie anschließend, welche Repositories diese Vorlage aufrufen. Umgekehrt reicht es nicht, nur die Aufrufer zu ändern, wenn ein zentraler Workflow selbst weiterhin ein altes Label festlegt.

Berücksichtigen Sie auch generierte Konfigurationen: Ein Workflow kann aus einer Vorlage oder einem internen Generator entstehen und im Repository nur als abgeleitete Datei sichtbar sein. Notieren Sie den Generator, seine Eingaben und die resultierende Workflow-Datei. Sonst kann eine direkte Korrektur beim nächsten Generierungslauf wieder überschrieben werden.

Wichtig: Ein fehlender Texttreffer belegt nur, dass die durchsuchten Inhalte keine passende Zeichenfolge enthielten. Er beweist weder, dass alle Repositories erreichbar waren, noch dass Laufzeit-Ausdrücke, erzeugte Workflows und nicht regelmäßig ausgeführte Aufgaben abgedeckt wurden.

Die tatsächliche Nutzung anhand von Läufen belegen

Statische Suche und Laufhistorie beantworten unterschiedliche Fragen. Die Suche zeigt, wo ein altes Label konfiguriert sein kann. Ein Lauf zeigt, ob und in welchem Zusammenhang eine Workflow-Definition tatsächlich ausgeführt wurde. Für die Entscheidung benötigen Sie beides, denn ein Workflow kann auf einem seltenen Ereignis beruhen oder nur manuell gestartet werden.

Erfassen Sie zu jedem relevanten Lauf mindestens Repository und Workflow, auslösendes Ereignis, verwendetes Runner-Label sowie das Datum und Ergebnis des jüngsten auffindbaren Laufs. Wo ein Laufprotokoll das tatsächlich zugewiesene Label nicht ausweist, markieren Sie diese Einschränkung, statt den Konfigurationswert als Laufnachweis auszugeben. Die GitHub-REST-API für Workflow-Läufe kann beim Abruf von Laufdaten helfen; klären Sie vorab, ob Berechtigungen und Aufbewahrung in Ihrer Organisation eine vollständige Auswertung erlauben.

Suchen Sie gezielt nach Aufgaben mit ungewöhnlichen Auslösern: geplanten Regressionstests, manuell gestarteten Builds, Release-Vorbereitungen und Workflows, die nur in einem bestimmten Zweig laufen. Eine Pipeline ohne kürzlich sichtbare Ausführung ist nicht automatisch entbehrlich. Sie kann gerade deshalb übersehen werden, weil sie erst bei einer seltenen Freigabe oder einem besonderen Betriebsfall benötigt wird.

Trennen Sie außerdem den Status „Konfiguration gefunden“ vom Status „Laufverhalten nachgewiesen“. Bei einem statischen Treffer ohne verfügbaren Lauf bleibt die Abhängigkeit offen, bis der zuständige Verantwortliche sie durch einen Test, eine nachvollziehbare Analyse oder eine genehmigte Ausnahme bewertet. Bei einem tatsächlichen Lauf ohne auffindbaren Konfigurationsursprung müssen Sie den Erzeugungs- oder Wiederverwendungsweg weiterverfolgen.

Kritische Workloads vor der Umstellung abnehmen

Bewerten Sie nicht allein, ob ein Workflow erfolgreich endet. Fragen Sie, welche Geschäftsaufgabe er absichert und welche Folgen ein Fehler hätte. Ein Pull-Request-Test kann einen Merge verzögern; ein Signatur- oder Release-Workflow kann dagegen eine geplante Auslieferung blockieren. Diese Unterschiede bestimmen, welche Nachweise vor einer Freigabe erforderlich sind.

Ordnen Sie jeden Fund einer Aufgabenklasse zu: Pull-Request-Prüfung, zeitgesteuerter Regressionstest, Build, Signierung, Veröffentlichung oder sonstiger Betriebsvorgang. Ergänzen Sie den fachlichen Verantwortlichen sowie die verwendeten Toolchain-Anforderungen. Ist etwa eine bestimmte Xcode-Version oder ein festgelegter Signaturablauf notwendig, sollte diese Bindung als überprüfbare Anforderung erscheinen und nicht als allgemeine Vermutung über Runner-Leistung.

GitHub nennt in der Abschaltungsmitteilung die betroffenen Labels, die Übergangsplanung einschließlich Brownout-Zeiträumen und empfohlene Ersatz-Labels. Übernehmen Sie die dort aktuell angegebenen Ersatzwerte in Ihren Testplan, statt sie aus älteren internen Vorlagen abzuleiten. Ein offiziell empfohlener Runner ist jedoch nicht automatisch für Ihren Build, Ihre Tests oder Ihre Veröffentlichung abgenommen.

Führen Sie die Migration zunächst mit einem repräsentativen Projekt je relevanter Aufgabenklasse durch. Vergleichen Sie die bisherige Konfiguration mit der Änderung und lassen Sie den vollständigen erforderlichen Ablauf laufen: nicht nur Kompilierung, wenn danach Tests, Signierung oder Veröffentlichung dazugehören. Halten Sie fest, welche Schritte erfolgreich waren, was abwich und welche Aufgaben noch nicht getestet wurden. Ziehen Sie aus einem einzelnen erfolgreichen Pull-Request-Build keine Freigabe für alle Release-Pipelines.

Abnahmekriterien für die Umstellung:

• Die Ersatz-Labels stammen aus der aktuellen offiziellen Empfehlung; Sie haben die Angabe vor der Änderung erneut geprüft.
• Der Test umfasst die für den jeweiligen Workload erforderlichen Build-, Test- und Freigabeschritte.
• Konfigurationsänderung und Testergebnis sind einander eindeutig zugeordnet.
• Offene Toolchain- oder Kompatibilitätsfragen haben einen Verantwortlichen und blockieren die Freigabe, wenn sie einen kritischen Ablauf betreffen.
• Zeitweilige Ausnahmen sind begründet, genehmigt und mit einem Termin oder konkreten Auslöser zur erneuten Prüfung versehen.

FAQ zur Prüfung der alten macOS-Runner-Labels

Die Antworten fassen die typischen Such- und Abnahmefragen zusammen. Für den verbindlichen Abschalttermin und die betroffenen Labels ist die aktuelle GitHub-Ankündigung maßgeblich.

Wann wird der macOS-14-Runner in GitHub Actions abgeschaltet?

GitHub hat die Außerbetriebnahme der macOS-14-Runner-Images für den 02.11.2026 angekündigt. Betroffen sind macos-14, macos-14-large und macos-14-xlarge. Prüfen Sie zusätzlich die im offiziellen Hinweis genannten Brownout-Zeiträume und Ersatz-Labels, bevor Sie einen internen Umstellungstermin festlegen; diese Angaben können für Ihre Planung entscheidend sein. (Quelle)

Wie finde ich Workflows, die noch macos-14 verwenden?

Suchen Sie nicht nur in den YAML-Dateien des Standardzweigs. Prüfen Sie auch aktive Zweige, wiederverwendbare Workflows, aufrufende Parameter, Matrix-Ausdrücke und generierte Konfigurationen. Vergleichen Sie Treffer anschließend mit tatsächlichen Workflow-Läufen und dokumentieren Sie Repository, Workflow, Auslöser, Label-Quelle und letzte nachvollziehbare Ausführung. So bleibt sichtbar, welche Abhängigkeiten noch nicht überprüft sind.

Wie prüfe ich Runner-Labels in wiederverwendbaren Workflows?

Verfolgen Sie den Wert vom aufrufenden Workflow bis zum wiederverwendbaren Workflow. Ein Label kann als Eingabe übergeben, in einer Matrix zusammengesetzt oder innerhalb eines Ausdrucks ausgewertet werden. Dokumentieren Sie deshalb sowohl die Stelle, an der der Wert gesetzt wird, als auch die Stelle, an der er für runs-on verwendet wird. Ein Texttreffer an nur einer dieser Stellen liefert keine vollständige Abhängigkeitsspur.

Woran erkenne ich, dass alle betroffenen Repositories erfasst sind?

Legen Sie den organisatorischen Umfang vor der Suche fest und führen Sie eine Liste der geprüften, nicht erreichbaren und begründet ausgenommenen Repositories. Gleichen Sie statische Treffer mit Workflow-Ausführungen ab, einschließlich manueller und zeitgesteuerter Abläufe. Erst wenn jeder Fund einen Verantwortlichen, einen Migrationsstatus und einen prüfbaren Nachweis besitzt, können Sie die Abdeckung als belegt statt lediglich vermutet einstufen.

Offene Abhängigkeiten als Freigabeentscheidung behandeln

Schließen Sie die Bestandsaufnahme nicht mit einer pauschalen Aussage wie „keine Treffer mehr“ ab. Entscheidend ist, ob jeder gefundene Fall entweder migriert und getestet, als nicht mehr relevant belegt oder als begründete Ausnahme freigegeben wurde. Nicht zugängliche Repositories, ungeprüfte Aufrufer und fehlende Laufnachweise gehören in die offene Liste.

Für eine Ausnahme sollten Sie mindestens die betroffene Aufgabe, die geschäftliche Auswirkung, die technische Blockade, den Verantwortlichen und die geplante Neubewertung dokumentieren. Eine Ausnahme ohne Eigentümer oder Endpunkt wird leicht zum dauerhaften, unsichtbaren Risiko. Lassen Sie kritische Signatur- und Veröffentlichungsaufgaben nicht allein aufgrund eines erfolgreichen allgemeinen Builds als erledigt gelten.

Der abschließende Abgleich sollte aus drei getrennt prüfbaren Ergebnissen bestehen: vollständige Repository- und Konfigurationsabdeckung, nachvollziehbare Zuordnung zu realen Läufen und dokumentierte Migrationsabnahme je Workload. Erst wenn diese Ergebnisse zusammenpassen, können Sie den Umfang der GitHub Actions macOS 14 Runner-Abschaltung für Ihre Organisation als kontrolliert bewerten.

Wenn Ihre heutigen gehosteten Runner vor allem deshalb bequem sind, weil GitHub die Ausführungsumgebung verwaltet, bleiben dennoch Abhängigkeiten von verfügbaren Runner-Images, festgelegten Labels und deren Lebenszyklus. Ein eigener Mac bringt im Gegenzug Betriebsverantwortung für Zugriff, Updates, Kapazität und Sicherheitskontrollen mit sich; er ist deshalb nicht automatisch die bessere Wahl. Muss ein verifizierter Build- oder Signatur-Workload jedoch in einer kontrollierten Mac-Umgebung laufen, kann ein gemieteter echter Mac besser passen als eine ungeprüfte Verlängerung der alten Label-Abhängigkeit. Prüfen Sie dafür zunächst die Einsatzmöglichkeiten für Mac-CI und vergleichen Sie den Bedarf mit den Mietoptionen von KVMFLUX. Für die Betriebsplanung eines eigenen Mac-Knotens kann außerdem der Leitfaden zur Wiederherstellung eines Mac-Packservers relevant sein.

Weiterlesen

• GitHub-Actions-macOS-Runner skalierbar und sicher betreiben
• Self-hosted Runner auf einem Remote Mac einrichten und absichern
• Cloud- und eigenes Mac-CI für Unternehmen vergleichen

Häufige Fragen