Beobachtung: Die Jenkins-Dokumentation beschreibt die Bereinigung des Workspace als ausdrücklich konfigurierbaren Schritt; ein Pipeline-Arbeitsbereich wird also nicht zwangsläufig nach jedem Lauf automatisch entfernt (Workspace-Cleanup-Dokumentation). Schnellste Entscheidung: Ermitteln Sie zuerst, ob Workspace, Xcode-Komponenten oder Build-Artefakte den Speicher belegen. Bereinigen Sie danach gezielt und mit einer festgelegten Aufbewahrungsregel; löschen Sie nicht pauschal Verzeichnisse. Werden die Warnungen trotz kontrollierter Bereinigung wiederholt ausgelöst, vergleichen Sie die tatsächliche Last mit der vorhandenen Mac-CI-Kapazität.
Dieser Leitfaden ist für Sie geeignet, wenn Sie als IT-Verantwortliche oder IT-Verantwortlicher Speicherwarnungen auf einem Mac-Build-Knoten auf ihre Auswirkungen auf die CI-Stabilität prüfen. Auch Plattformverantwortliche, die Jenkins Mac Agent, Workspace und Xcode-Umgebungen betreiben, erhalten hier einen Ablauf für Diagnose und Abnahme. Technische Leitung und Verantwortliche für Entwicklerproduktivität finden Kriterien, um Bereinigungsregeln und zusätzliche oder anders verteilte Mac-Kapazität anhand realer Auftragsdaten zu vergleichen.
Jenkins Mac Agent bei knappem Speicher systematisch prüfen
Eine Warnung zur Speicherbelegung, ein fehlgeschlagener Schreibvorgang und ein fehlgeschlagener Jenkins-Build sind unterschiedliche Beobachtungen. Behandeln Sie sie zunächst nicht als denselben Fehler: Ein Build kann wegen eines Netzwerkproblems, einer Warteschlange oder eines Werkzeugkettenfehlers scheitern, während eine Speicherwarnung gleichzeitig, aber unabhängig davon auftritt. Umgekehrt kann ein voller Datenträger Schreibvorgänge während eines Builds verhindern. Erst ein zeitlicher und sachlicher Zusammenhang in den eigenen Protokollen stützt die Diagnose.
Sammeln Sie für denselben Zeitraum die Speichermeldungen des Hosts, den betroffenen Job, den fehlgeschlagenen Pipeline-Schritt und den dazugehörigen Fehlertext. Halten Sie fest, ob der Fehler beim Checkout, beim Kompilieren, beim Test, beim Archivieren oder beim Ablegen eines Ergebnisses auftrat. Vergleichen Sie diese Informationen mit erfolgreichen Läufen desselben Jobs. Ein Fehler, der nur bei einem bestimmten Schritt oder Auftrag erscheint, kann eine andere Ursache haben als eine auf dem Host fortlaufend zunehmende Belegung.
Für eine brauchbare Diagnose brauchen Sie konkrete Messwerte aus dem betroffenen Knoten, nicht allgemeine Annahmen über typische Xcode-Installationen. Erfassen Sie den verfügbaren Speicher vor und nach einem repräsentativen Build, die Belegung der relevanten Verzeichnisse und die Größe der erzeugten oder aufbewahrten Artefakte. Die Speicherübersicht von macOS hilft, Kategorien des belegten Speichers einzuordnen; sie ersetzt aber nicht die Zuordnung einzelner Jenkins-Jobs zu deren Workspace und Ausgaben (Apple-Anleitung zur Speicherverwaltung auf dem Mac).
Protokollieren Sie außerdem die genaue Fehlermeldung statt nur den Status „Build fehlgeschlagen“. Meldet ein Schritt, dass kein Speicherplatz mehr verfügbar ist, ist das ein anderer Hinweis als ein abgebrochener Checkout oder ein fehlgeschlagener Simulatorstart. Die Pipeline-Dokumentation von Jenkins beschreibt, wie Schritte und Bedingungen in einem Pipeline-Ablauf angeordnet werden; prüfen Sie deshalb den tatsächlichen Jobverlauf und nicht nur den abschließenden Build-Status (Jenkins-Dokumentation zu Pipeline-Syntax und -Abläufen).
Welche Verzeichnisse sollte Ihre erste Bestandsaufnahme abdecken? Beginnen Sie beim Workspace des betroffenen Jobs, den zugehörigen Xcode-Komponenten und Simulator-Laufzeitumgebungen sowie den Speicherorten für Archive, Protokolle, Testergebnisse und temporäre Ausgaben. Nehmen Sie zusätzlich andere große, jobübergreifende Verzeichnisse in die Bestandsaufnahme auf, falls sie auf dem Host vorhanden sind. Das ist eine Prüfreihenfolge, keine Aufforderung, sämtliche genannten Inhalte zu löschen.
Workspace-Reste von gemeinsam genutzten Build-Daten trennen
Ein Workspace kann nach einem Lauf erhalten bleiben, wenn der Job keine Bereinigung vorsieht oder wenn eine Bereinigung nur für bestimmte Ausgänge ausgeführt wird. Die tatsächliche Wirkung hängt von der Pipeline-Konfiguration ab. Prüfen Sie deshalb sowohl die Jenkinsfile als auch die Job-Einstellungen und den protokollierten Ablauf, bevor Sie eine Bereinigungsregel ändern. Die Jenkins-Dokumentation zum Workspace Cleanup beschreibt den dafür verfügbaren Schritt und seine Optionen.
Beachten Sie nicht nur erfolgreiche Builds. Ein fehlgeschlagener oder abgebrochener Auftrag kann Dateien zurücklassen, die bei späteren Läufen erneut Platz belegen. Diese Reste können zugleich für die Fehlersuche wichtig sein: Projektzustand, Zwischenergebnisse und Protokolle helfen dabei, einen Fehler zu reproduzieren. Wenn eine Bereinigung unmittelbar nach jedem Lauf alle Belege entfernt, kann ein späterer Vorfall schwerer zu untersuchen sein. Legen Sie daher fest, welche Daten bei Erfolg entfernt werden dürfen und welche bei einem Fehler bis zur abgeschlossenen Diagnose erhalten bleiben müssen.
Auch parallele Aufträge sind relevant. Ein gemeinsam verwendeter Knoten kann gleichzeitig mehrere Workspaces oder zusätzliche Ausgaben laufender Jobs enthalten. Ein Blick auf einen einzelnen Workspace sagt dann nicht aus, wie viel Speicher der gesamte Jenkins-Betrieb auf dem Host beansprucht. Erfassen Sie, welche Aufträge zeitgleich aktiv waren, und ordnen Sie deren Daten getrennt zu. Wenn die Belegung vor allem während paralleler Builds steigt, muss eine Bereinigungsregel nicht ausreichen: Die Gleichzeitigkeit der Aufträge kann Teil der Ursache sein.
Entfernt die Bereinigung eines Jenkins-Workspaces Dateien, die Sie behalten müssen? Sie kann Dateien entfernen, die noch zur Fehleranalyse oder Reproduktion eines Builds benötigt werden, wenn ihre Bereinigung nicht an den Build-Ausgang und die Aufbewahrungsanforderungen angepasst ist. Definieren Sie deshalb, welche Workspace-Daten nach einem erfolgreichen Lauf entfallen dürfen und welche Belege bei einem Fehler zunächst erhalten bleiben. Testen Sie die Regel mit einem kontrollierten Auftrag, bevor Sie sie auf alle Jobs anwenden.
Ändern Sie Bereinigungsregeln zunächst für einen repräsentativen Job. Prüfen Sie anschließend, ob der nächste Lauf seine Abhängigkeiten neu beziehen kann, ob der Workspace im erwarteten Zustand beginnt und ob Fehlerbelege verfügbar bleiben. Dokumentieren Sie die Regel zusammen mit den Pipeline-Einstellungen. So können Sie nach einer Änderung unterscheiden, ob ein Build-Fehler durch die Bereinigung oder durch eine unabhängige Ursache entstanden ist.
Xcode-Komponenten und Simulator-Laufzeitumgebungen getrennt bewerten
Xcode-Installationen können neben der eigentlichen Entwicklungsumgebung zusätzliche Plattformunterstützung und optionale Komponenten enthalten. Apple beschreibt, dass zusätzliche Xcode-Komponenten verwaltet und nicht mehr verwendete Komponenten entfernt werden können (Apple-Dokumentation zur Verwaltung zusätzlicher Xcode-Komponenten). Daraus folgt jedoch nicht, dass jede Komponente auf jedem Build-Knoten entbehrlich ist. Prüfen Sie zuerst, welche Xcode-Versionen, Plattformen und Tests die tatsächlichen Jobs benötigen.
Simulator-Laufzeitumgebungen sind ebenfalls nicht mit dem Xcode-Programm selbst gleichzusetzen. Die verfügbaren Simulatoren und ihre Verwaltung hängen vom installierten Komponentenbestand und den Testanforderungen ab; Apple beschreibt das Hinzufügen zusätzlicher Simulatoren in der Dokumentation zur Simulator-Verwaltung. Vor einer Entfernung gleichen Sie die installierten Laufzeitumgebungen daher mit den Pipeline-Konfigurationen, den verwendeten Simulatoren und den Ergebnissen repräsentativer Tests ab.
Kann eine Xcode-Simulator-Laufzeitumgebung sicher entfernt werden? Ja, wenn Sie zuvor belegt haben, dass kein aktiver Job oder freizugebender Testlauf diese Laufzeitumgebung benötigt, und Sie sie über die von Apple vorgesehene Komponentenverwaltung entfernen. Wenn ihre Nutzung nicht eindeutig zugeordnet ist, lassen Sie sie zunächst bestehen und protokollieren Sie ihre Belegung. Löschen Sie nicht auf Verdacht Inhalte aus geschützten oder von Xcode verwalteten Systemverzeichnissen. Eine manuelle Entfernung kann den Komponentenbestand in einen Zustand bringen, den Sie nicht zuverlässig über die vorgesehene Verwaltung nachvollziehen können.
Prüfen Sie nach einer Komponentenbereinigung, ob die Jobs weiterhin die erwartete Xcode-Version und Plattform auswählen können. Ein erfolgreicher Start des Jenkins-Agenten allein ist keine ausreichende Abnahme: Der Knoten muss auch den tatsächlichen Compile-, Test- und Archivierungspfad der betroffenen Projekte ausführen. Wo ein Projekt Release-Builds erstellt, sollten diese gesondert geprüft werden; Apples Anleitung zum Testen eines Release-Builds behandelt diesen Prüfschritt.
Halten Sie fest, welche Komponente entfernt wurde, weshalb sie als nicht benötigt galt und welche Jobs Sie danach ausgeführt haben. Diese Dokumentation verhindert, dass eine spätere Änderung an einer Pipeline unbemerkt eine zuvor entfernte Plattform oder Simulatorumgebung voraussetzt. Sie macht außerdem sichtbar, ob der freigegebene Speicher eine dauerhafte Wirkung hatte oder ob die Belegung durch andere Inhalte wieder anwächst.
Build-Artefakte nach Aufbewahrungszweck ordnen
Archive, Symboldateien, Testberichte, Protokolle und temporäre Ausgaben sind nicht gleichwertig. Ein neu erzeugbarer Cache kann nach einer dokumentierten Regel anders behandelt werden als ein Archiv, das für Veröffentlichung oder Rückfragen benötigt wird. Testberichte und Fehlerprotokolle können für die Diagnose erforderlich sein. Bevor Sie eine Bereinigung automatisieren, ordnen Sie jede Artefaktart einem Zweck, einer verantwortlichen Person oder einem Team und einer Aufbewahrungsregel zu.
Unterscheiden Sie dabei zwischen drei Fragen: Kann der Inhalt aus versionierten Quellen erneut erzeugt werden? Wird er für eine Freigabe, einen späteren Nachweis oder eine interne Prüfung benötigt? Kann er außerhalb des Mac-Knotens so archiviert werden, dass ein Build ihn bei Bedarf weiterhin erreicht? Solange diese Punkte ungeklärt sind, behandeln Sie den Inhalt nicht als entbehrlichen Cache. Das Löschen einer Datei schafft zwar Platz, kann aber zugleich die Grundlage für die Analyse eines Build-Fehlers oder die Nachvollziehbarkeit einer Veröffentlichung entfernen.
Suchen Sie außerdem nach doppelten Ablagen. Ein Bericht kann sowohl im Workspace als auch in einem gesonderten Aufbewahrungsort liegen; ein Archiv kann im Job-Ausgabeverzeichnis und zusätzlich in einer kontrollierten Ablage gespeichert sein. Ob tatsächlich Duplikate vorhanden sind, muss Ihre Bestandsaufnahme zeigen. Leiten Sie daraus keine allgemeine Löschregel ab, bevor Sie die Funktion beider Kopien geprüft haben.
Für Jenkins-Jobs lässt sich Bereinigung als Pipeline-Schritt kontrollieren; welche Dateien erfasst werden und wann er greift, muss zu Ihrer Job- und Aufbewahrungslogik passen. Prüfen Sie Optionen und Verhalten anhand der offiziellen Dokumentation zum Workspace-Cleanup-Schritt und testen Sie das Ergebnis mit einem kontrollierten Lauf. Bewahren Sie die ursprüngliche Pipeline-Konfiguration oder eine nachvollziehbare Änderung auf, damit Sie bei unerwartetem Verhalten zur vorherigen Regel zurückkehren können.
Bereinigung kontrolliert ausrollen und Build-Fähigkeit abnehmen
Führen Sie die Änderung nicht als pauschalen Eingriff auf sämtlichen Knoten aus. Verwenden Sie diesen Ablauf, um eine Regel zunächst auf einem betroffenen Job zu prüfen und danach nur bei erfolgreicher Abnahme auf vergleichbare Jobs zu übertragen:
- [ ] Erfassen Sie vor der Änderung verfügbaren Speicher, betroffene Verzeichnisse, laufende Jobs und die genaue Fehlermeldung.
- [ ] Ordnen Sie die belegten Inhalte dem Workspace, Xcode-Komponenten, Simulator-Laufzeitumgebungen oder Build-Artefakten zu.
- [ ] Definieren Sie pro Datenart, was nach einem erfolgreichen Build entfernt werden darf und was bei Fehlern für Diagnose, Veröffentlichung oder Nachweis erhalten bleiben muss.
- [ ] Ändern Sie die Bereinigungsregel zunächst für einen repräsentativen Job und dokumentieren Sie Konfiguration sowie erwartete Wirkung.
- [ ] Führen Sie den betroffenen Build-Pfad erneut aus und prüfen Sie Checkout, Abhängigkeitsauflösung, Xcode-Auswahl, Simulatorauswahl und die benötigten Ergebnisse.
- [ ] Vergleichen Sie die Speichermessung nach dem Lauf mit dem vorherigen Zustand und kontrollieren Sie, ob erforderliche Berichte und Fehlerbelege weiterhin verfügbar sind.
- [ ] Legen Sie eine Rückkehr zur vorherigen Regel fest, falls der Testlauf Daten verliert, einen bisher funktionierenden Build-Pfad beschädigt oder die Ursache nicht eindeutig bleibt.
Halten Sie nach der Änderung dieselben Messgrößen fest wie bei der Bestandsaufnahme: verfügbare Speichermenge, Belegung der relevanten Verzeichnisse, betroffene Jobs und Größe der neu erzeugten Artefakte. So entsteht aus der Bereinigung ein überprüfbarer Vergleich statt einer bloßen Einschätzung, dass der Knoten „wieder genug Platz“ habe. Eine einzelne Messung nach einem erfolgreichen Lauf beweist noch nicht, dass sich das Problem bei parallelen oder fehlerhaften Jobs nicht erneut zeigt.
Wiederkehrende Warnungen anhand Ihrer Last bewerten
Wenn der Speicher nach einer kontrollierten Bereinigung erneut knapp wird, suchen Sie nicht automatisch nach weiteren Verzeichnissen zum Löschen. Vergleichen Sie über einen repräsentativen Zeitraum, welche Inhalte nach den Läufen verbleiben, wie oft Bereinigungen nötig sind, welche Artefakte aufbewahrt werden müssen und wann Jobs gleichzeitig laufen. Diese Daten zeigen, ob die Ursache ein fehlender Aufbewahrungsprozess, ein zu großer Workspace, die installierte Xcode-Komponentenauswahl oder eine dauerhaft nicht passende Knotenlast ist.
Die folgenden Tabellen sind Entscheidungshilfen, keine Aussage über eine allgemeingültige Kapazitätsgrenze. Bewerten Sie jede Ursache anhand der eigenen Build-Aufzeichnungen. Die Bewertung „hoch“ bedeutet hier, dass die entsprechende Maßnahme als Nächstes untersucht werden sollte; sie ist keine Messung der Leistung oder eine Zusage über den erzielbaren Speichergewinn.
| Beobachtung in Ihren Aufzeichnungen | Bewertung für die Ursachenprüfung | Nächster Schritt |
|---|---|---|
| Workspace-Belegung bleibt nach Jobs bestehen, die keinen späteren Zugriff benötigen | Hoch für die Prüfung der Bereinigungsregel | Bereinigung gezielt für Erfolg und Fehler definieren, dann mit einem Job abnehmen |
| Belegung liegt überwiegend bei Xcode-Komponenten oder Simulator-Laufzeitumgebungen | Hoch für die Prüfung des Komponentenbedarfs | Installierte Komponenten mit den tatsächlich verwendeten Toolchain- und Testanforderungen abgleichen |
| Archive, Berichte oder Protokolle wachsen an einem bekannten Ablageort | Hoch für die Prüfung der Aufbewahrung | Zweck, verantwortliche Stelle und zulässige Ablagefrist klären, bevor Sie löschen |
| Warnungen treten vor allem bei gleichzeitig laufenden Aufträgen auf | Hoch für die Prüfung der Lastverteilung | Parallelität und gleichzeitige Ausgaben anhand der Jobverläufe untersuchen |
| Ursache bleibt trotz Zuordnung unklar oder erforderliche Daten lassen sich nicht sicher bereinigen | Hoch für weitere Diagnose, nicht für pauschales Löschen | Protokolle und Messungen erweitern und Änderungen zunächst zurückstellen |
| Ergebnis der Diagnose | Geeignete Entscheidung | Abnahmekriterium |
|---|---|---|
| Ursache ist ein unnötig aufbewahrter Workspace oder entbehrlicher Cache | Bereinigungs- und Aufbewahrungsregel anpassen | Repräsentativer Build erfolgreich; benötigte Fehlerbelege und Ergebnisse bleiben verfügbar |
| Ursache ist eine nicht benötigte Xcode-Komponente | Über Apples Komponentenverwaltung entfernen | Betroffene Compile-, Test- und Release-Pfade bestehen die Prüfung |
| Ursache sind benötigte Archive, Berichte oder Nachweise | Aufbewahrung und Ablage prüfen, nicht blind löschen | Zugriff und geforderte Nachvollziehbarkeit bleiben erhalten |
| Wiederkehrende Last lässt sich mit sicheren Bereinigungsregeln nicht auffangen | Mac-CI-Knoten oder Lastverteilung anhand realer Auftragsdaten neu bewerten | Der Kapazitätsentscheid stützt sich auf gemessene Belegung, Parallelität und Aufbewahrungsbedarf |
Wenn Sie einen zusätzlichen oder anders bereitgestellten Mac-Knoten als mögliche Option untersuchen, vergleichen Sie dessen tatsächliche Ausstattung, Zugriffsmodell, Bereitstellung und Laufzeit mit Ihren Anforderungen, statt eine Entlastung vorauszusetzen. Über die Mac-Optionen von MACGPU können Sie die verfügbaren Möglichkeiten als Ausgangspunkt für diese Prüfung heranziehen. Prüfen Sie vor einer Entscheidung, ob Ihr Sicherheitsmodell, Ihre Datenaufbewahrung und Ihre Pipeline-Anforderungen zu einem gemieteten Remote-Mac passen. Für CI-Betrieb und kurzfristige Tests kann diese Variante sinnvoll zu prüfen sein; bei dauerhaft hoher, stabiler Auslastung oder benötigten physischen Schnittstellen kann ein eigener Mac die passendere Lösung bleiben. Details zu einer möglichen Mac-Miete von MACGPU sollten Sie deshalb mit Ihren realen Anforderungen und den aktuellen Angebotsangaben abgleichen.