Nach dem ersten macOS-14-Brownout: Build-Umgebung vor dem Labelwechsel erfassen
Wenn ein iOS-Build keinen Runner erhält, prüfe zuerst Zeit und Label. Der erste geplante macOS-14-Brownout lief vom 5. Oktober 14:00 bis 6. Oktober 00:00 UTC, also 23:00 bis 09:00 KST.
GitHub kündigte am 1. Oktober das Ende des Images zum 2. November an. Dieser Beitrag nutzt die am 6. Oktober 2026 geprüfte Mitteilung und Imageliste. Der Prüfablauf ist unser Vorschlag, keine GitHub-Pflicht.
Unterbrechung und Abschaltung unterscheiden
Betroffen sind macos-14, macos-14-large und macos-14-xlarge. Das Ende des ersten Brownouts hebt die Abschaltung nicht auf. Weitere Unterbrechungen und mögliche Kapazitätsreduktionen bleiben relevant.
Das nächste Intervall ist 12. Oktober 14:00 bis 13. Oktober 00:00 UTC, entsprechend 23:00 bis 09:00 KST. Vergleiche Logs und Dienststatus; der Termin erklärt nicht jeden Fehler.
Auch die CPU des Ersatzes lesen
Die Mitteilung empfiehlt arm64-Alternativen wie macos-latest (macos-26), macos-15 und aufgeführte xlarge-Varianten. Die Imageliste unterscheidet sie von bestimmten large- oder intel-x64-Labels.
Beim Wechsel von macos-14-large prüfst du alte und neue Architektur. Native Abhängigkeiten, Simulatoren, Cache und Paketierung können Unterschiede zeigen. Projektverträglichkeit muss getestet werden.
Den Commit konstant halten
Erfasse tatsächliches Label, OS, CPU, Xcode, SDK und Lockdatei. Baue und teste denselben Commit mit derselben Lockdatei auf dem Kandidaten. Vermische die Untersuchung nicht mit Quellcodeänderungen.
Prüfe neben grünen Checks auch Archiv, Tests sowie nötige Signierung und Export. Ein Lauf ohne alleinige Abhängigkeit vom alten Cache zeigt, ob das Ergebnis im neuen Umfeld reproduzierbar ist.
latest fixiert keine Umgebung
Laut offiziellem Repository verweist latest auf das neueste stabile OS; Umstellungen können schrittweise erfolgen. Explizite Version und tatsächliche Imageinformationen erleichtern Vergleiche, garantieren aber keinen ewigen Support.
latest kann für Teams mit laufender Prüfung sinnvoll sein. Entscheidend sind Verantwortliche, Belege und Kriterien für Reparatur oder Rückkehr, nicht eine pauschale Vorliebe für ein Label.
Vergleich und Verantwortung festhalten
CI-Unterbrechungen machen den Runner-Lebenszyklus zur Betriebsfrage. Wir behaupten keine gemessene Ausfallhäufigkeit der Community. Offizieller Termin und eigene Workflow-Belege tragen die Entscheidung.
Suche auch wiederverwendbare Workflows nach macOS 14. Dokumentiere Kandidatenlauf, Verantwortliche, nächste Prüfung, echte Toolversionen und offene Fehler. Nutze die Zeit bis zum nächsten Brownout zur Verifikation.