Bitbucket Pipelines macOS Runner: Go-live-Standard 2026

Ein macOS Runner führt Pipeline-Schritte auf dem Host aus. Das ist der entscheidende Unterschied zu einer Umgebung, in der jeder Job automatisch in einer kurzlebigen, vollständig isolierten Laufzeit startet. Die offizielle Atlassian-Dokumentation für macOS Runner beschreibt die Einrichtung auf dem Mac; sie ersetzt jedoch keine interne Sicherheitsabnahme.

Für Ihre Entscheidung sind vier Risiken besonders relevant:

• Ein Skript kann Dateien außerhalb des Arbeitsverzeichnisses schreiben.
• Ein Build kann globale Werkzeuge installieren oder einen dauerhaften Dienst starten.
• Verbliebene Prozesse können nachfolgende Jobs beeinflussen oder Ports belegen.
• Zertifikate, Profile, Umgebungsvariablen und Caches können länger verfügbar bleiben als vorgesehen.

Das Risiko entsteht nicht nur durch böswilligen Code. Auch ein fehlerhaftes Installationsskript, ein vergessener Cleanup-Schritt oder ein abgebrochener Build kann den Host verändern. Bei externen Beiträgen und nicht vollständig geprüften Repositorys ist deshalb ein gemeinsamer Runner mit Signaturzugriff keine angemessene Standardumgebung.

Abnahmeentscheidung als Bedingungsliste

Nutzen Sie diese Verzweigung vor der Produktionsfreigabe:

• Wenn der Job nur geprüften Quellcode verarbeitet, keine Apple-Signatur benötigt und der Host nach jedem Lauf nachweisbar bereinigt wird, dann kann ein kontrollierter interner Runner-Pool ausreichen.
• Wenn der Job Artefakte veröffentlicht, Signaturmaterial verwendet oder Zugriff auf Produktionssysteme besitzt, dann wählen Sie einen dedizierten Produktionspool.
• Wenn externe Beiträge, Pull Requests unbekannter Herkunft oder nicht vertrauenswürdige Skripte verarbeitet werden, dann routen Sie diese Jobs in einen separaten Pool ohne Produktions-Keychain.
• Wenn ein Test nach einem Neustart, einer Netzwerkunterbrechung oder einem abgebrochenen Job nicht reproduzierbar bestanden wird, dann stoppen Sie die Freigabe und lassen den Knoten nicht weiter signieren.
• Wenn die reale Warteschlange trotz korrekter Labels wächst, dann erhöhen Sie die geprüfte Runner-Kapazität. Kaufen Sie nicht allein nach Entwicklerzahl oder Chipbezeichnung.

Die zentrale Frage lautet nicht: „Ist der Runner erreichbar?“ Sie lautet: „Was kann ein einzelner Job dauerhaft verändern?“

Prüfen Sie zunächst, ob der Build in sein eigenes Arbeitsverzeichnis schreibt. Danach testen Sie gezielt Schreibversuche in globale Verzeichnisse, Benutzerprofile, Tool-Verzeichnisse und temporäre Speicherorte. Ein Zugriff darf nicht stillschweigend erlaubt werden, nur weil der normale Build ihn nicht benötigt.

Erfassen Sie anschließend die folgenden Zustände:

• Quelldateien und ausgecheckte Branches
• Xcode Derived Data und Build-Artefakte
• Paketmanager-Caches
• temporäre Dateien und Logs
• laufende Prozesse und belegte Ports
• Keychain-Einträge, Zertifikate und Provisioning-Profile
• Shell-Umgebungsvariablen und lokale Konfigurationsdateien

Trennen Sie dabei Plattformverhalten und Eigenverantwortung. Welche Dateien Bitbucket nach einem Schritt oder einer Pipeline entfernt, muss aus der aktuellen Dokumentation und Ihren Logs hervorgehen. Alles, was außerhalb dieses Bereichs liegt, gehört in Ihr eigenes Bereinigungs- oder Rotationsverfahren.

Erfahrung aus der Abnahme: Ein Cleanup-Skript ist kein Ersatz für Isolation. Wenn ein fremdes Repository vor der Bereinigung beliebige Host-Kommandos ausführen darf, kann es bereits Geheimnisse kopieren, Prozesse starten oder dauerhafte Änderungen erzeugen.

Für untrusted Code sollte der Knotenpool keine Produktionsschlüssel und keine wiederverwendbaren Signaturmaterialien enthalten. Bei besonders sensiblen Veröffentlichungen ist eine Knotenrotation nach dem Job stärker als eine lange Liste von Löschbefehlen. Diese Entscheidung muss mit dem Schutzbedarf, Ihren DSGVO-Vorgaben und den internen Nachweispflichten übereinstimmen.

Bitbucket Cloud kennt für Runner unterschiedliche Geltungsbereiche. Ein Repository Runner ist auf ein Repository bezogen. Ein Workspace Runner kann von mehreren Repositorys im Workspace verwendet werden. Die Atlassian-Übersicht zur Runner-Registrierung ist deshalb für die Autorisierung genauso wichtig wie für die technische Einrichtung.

Der größere Geltungsbereich eines Workspace Runner ist nicht automatisch falsch. Er erhöht aber die Anforderungen an Labels, Berechtigungen und Knotenpflege. Ein gemeinsam nutzbarer Pool sollte nur Jobs aufnehmen, die dasselbe Vertrauensniveau besitzen.

Die Zuordnung wird in bitbucket-pipelines.yml über runs-on gesteuert. Ein minimaler Ausschnitt kann beispielsweise so aussehen:

pipelines:
  branches:
    main:
      - step:
          name: iOS-Archiv erstellen
          runs-on:
            - self.hosted
            - macos
            - ios-release
          script:
            - xcodebuild -version
            - ./ci/build-release.sh

Die tatsächlichen Labelnamen legen Sie gemäß Ihrer Runner-Konfiguration fest. Entscheidend ist nicht die Bezeichnung, sondern die überprüfbare Wirkung. Die YAML-Routing-Dokumentation von Atlassian erläutert, wie Labels für die Auswahl genutzt werden.

Routing-Prüfung mit absichtlichen Fehlern

Führen Sie Ihre Tests nicht nur mit einem erfolgreichen Label aus. Entfernen Sie ein erforderliches Label. Verwenden Sie anschließend ein Label, das nur auf einem niedrig privilegierten Pool existiert. Prüfen Sie außerdem das Verhalten, wenn kein passender Knoten verfügbar ist.

Bestanden ist die Prüfung nur, wenn:

• ein Testjob nicht auf einen höher privilegierten Pool ausweichen kann;
• ein falsches Label nicht zufällig einen Produktionsrunner erreicht;
• ein beschäftigter Runner in der erwarteten Warteschlange bleibt;
• ein nicht passendes Label keine scheinbar erfolgreiche Ausführung erzeugt;
• Logs eindeutig zeigen, welcher Knoten den Job übernommen hat.

Ein Apple-Silicon-Knoten ist keine Garantie für identische Ergebnisse. Sie brauchen eine dokumentierte Basis aus macOS, Xcode, SDK, Build-Werkzeugen, Abhängigkeiten und Laufzeitkonto. Konkrete Versionen dürfen Sie nur aus der Dokumentation am Einsatztag und aus Ihrer eigenen Abnahme übernehmen. Eine pauschale Versionszusage wäre ohne diesen Nachweis nicht belastbar.

Beginnen Sie mit dem Werkzeugnachweis:

xcodebuild -version
xcode-select -p
uname -m

Die Apple-Referenz zu den Xcode-Command-Line-Tools beschreibt die verfügbaren Befehle. Die Ausgabe dieser Kommandos gehört als Beleg in Ihr Abnahmeprotokoll. uname -m hilft dabei, Architekturannahmen zu erkennen; es beweist jedoch nicht, dass jede Abhängigkeit nativ läuft.

Führen Sie denselben Commit unter identischen Pipeline-Bedingungen erneut aus. Vergleichen Sie:

• Dependency-Auflösung und Lockfile-Verwendung
• Cache-Treffer und Cache-Auslassungen
• Build- und Archivpfade
• erzeugte Bundle-Metadaten
• Warnungen und Exit-Codes
• Ergebnis nach vollständiger Bereinigung

Wenn der erste Lauf nur durch einen warmen Cache funktioniert, ist der Knoten noch nicht reproduzierbar abgenommen. Testen Sie deshalb auch einen Lauf ohne wiederverwendete Build-Artefakte. Caches sind eine Beschleunigungsmaßnahme, kein Beweis für eine unveränderte Umgebung.

Übernehmen Sie keine Linux- oder Cloud-Pipeline blind auf macOS. Shell-Pfade, Keychain-Verhalten, Dateirechte und verfügbare Runner-Funktionen können abweichen. Nicht unterstützte Funktionen brauchen einen dokumentierten Ersatzprozess. Für die Freigabe zählt der nachgewiesene Ablauf, nicht die Ähnlichkeit der YAML-Datei.

Ein Runner-Registrierungsgeheimnis ist nicht dasselbe wie ein Repository-Zugriffstoken. Apple-Zertifikate und Provisioning-Profile sind wiederum eine eigene Schutzklasse. Behandeln Sie diese Materialien getrennt:

• Runner-Registrierung
• Quellcodezugriff
• Paket- und Artefaktzugriff
• Apple-Signaturmaterial
• Veröffentlichungsberechtigungen

Speichern Sie keine privaten Schlüssel im Repository und legen Sie sie nicht in ein universelles Shell-Skript. Die Atlassian-Dokumentation zu Variablen und Secrets beschreibt die Verwaltung von Pipeline-Geheimnissen. Für die technische Einordnung von Apple-Zertifikaten ist Apple TN3161 zur Codesignierung maßgeblich.

Ihre Abnahme muss jeden Lebenszyklus abdecken:

• Import in eine dafür vorgesehene Keychain
• Nutzung nur durch den notwendigen Prozess
• Ausschluss aus Logs und Diagnosepaketen
• Entfernung nach dem Job
• planmäßige Rotation
• sofortige Sperrung bei Verdacht auf Offenlegung

Testen Sie außerdem, ob ein Job aus einem weniger privilegierten Pool auf Variablen, Keychains, Caches oder Archive des Release-Pools zugreifen kann. Ein negatives Ergebnis muss im Log oder durch einen kontrollierten Zugriffstest belegbar sein. Ein bloßes Versprechen, dass die Skripte „nicht darauf zugreifen“, genügt nicht.

Apple beschreibt die Anforderungen für signierten Code in der offiziellen Codesignierungsdokumentation. Für Ihre iOS-CI/CD-Pipeline bleibt zusätzlich entscheidend, wer den Schlüssel importieren darf, wie lange er existiert und ob der Host nach einem Fehler automatisch aus dem Pool entfernt wird.

Ein Produktionsrunner muss mehr können, als eine Pipeline bei Normalbetrieb auszuführen. Prüfen Sie einen Prozessabbruch, einen Runner-Ausfall, einen Mac-Neustart, eine Netzwerkunterbrechung und eine manuelle Job-Stornierung. Nach jedem Ereignis muss klar sein, ob der Knoten automatisch zurückkehrt, Jobs ablehnt oder manuell quarantänisiert wird.

Dokumentieren Sie für jedes Ereignis:

• Auslöser und Uhrzeit
• letzter bekannter Runner-Status
• Zustand des laufenden Jobs
• Wiederherstellung des Prozesses
• erneute Registrierung oder Label-Erkennung
• Zustand von Arbeitsbereich und Keychain
• Entscheidung zur Wiederaufnahme von Produktionsjobs

Trennen Sie dabei Plattformfähigkeit von Ihrer eigenen Infrastruktur. Die Atlassian-Hinweise zu Runner-Konkurrenz und Step-Warteschlangen sind die Grundlage für die Interpretation der Warteschlange. Die tatsächliche Wiederanlaufdauer und effektive Bauleistung müssen Sie selbst messen oder aus einem belastbaren Anbieterprotokoll beziehen.

Ein Kapazitätsmodell sollte mindestens diese Variablen enthalten:

• reale Build-Dauer je Pipeline-Typ
• Spitzenlast der gleichzeitig eintreffenden Jobs
• verfügbare Runner während Wartung
• Anteil fehlgeschlagener oder wiederholter Läufe
• Zeitverlust durch Bereinigung und Neustart
• Reserve bei Ausfall eines Knotens

Entscheiden Sie anhand der Warteschlangendaten, nicht anhand der Zahl Ihrer Entwickler. Ein Team mit wenigen Entwicklern kann durch parallele Archive eine höhere Last erzeugen als ein größeres Team mit seltenen Builds. Ebenso sagt ein Chipname nichts über Xcode-Abhängigkeiten, Cache-Verhalten oder Signaturwartezeiten aus.

Fassen Sie die Ergebnisse nicht in einer Gesamtbewertung wie „funktioniert“ zusammen. Verwenden Sie vier Betriebszustände:

• Pilot: Nur nicht produktive Pipeline, isolierter Pool, vollständige Protokollierung.
• Limitierte Produktion: Ausgewählte Repositorys und klar begrenzte Release-Aufgaben.
• Reguläre Produktion: Isolation, Routing, Reproduzierbarkeit, Signaturschutz, Wiederanlauf und Kapazität sind nachgewiesen.
• Zurück zur Nachbesserung: Ein Sicherheits-, Routing- oder Wiederanlauftest ist fehlgeschlagen.

Der nächste Schritt ist nicht automatisch ein weiterer Runner. Wenn die Bereinigung nicht zuverlässig ist, brauchen Sie zunächst eine bessere Isolation. Wenn die Jobs nur wegen falscher Labels auf dem Produktionsknoten landen, korrigieren Sie die Pipeline-Zuordnung. Wenn die Warteschlange wächst, vergleichen Sie gemessene effektive Kapazität mit dem realen Lastprofil.

Für zusätzliche Mac-Kapazität können Sie die Mac-Remote-Optionen von CALMVPS zunächst als getrennten Testpfad bewerten. Prüfen Sie dabei dieselben Kriterien wie bei eigener Hardware: Zugriffskontrolle, Fernzugriff, Wiederanlauf, Datenlöschung, Vertragsbedingungen und Nachweise für Ihre internen Audits. Preise und Lieferbedingungen sollten Sie erst nach der technischen Abnahme in das Beschaffungsmodell aufnehmen; einen Überblick finden Sie auf der CALMVPS-Preisseite.

Die folgenden Antworten decken die häufigsten Such- und Entscheidungsfragen rund um Bitbucket Cloud, Apple Silicon und iOS CI/CD ab.

Wie richten Sie einen macOS Runner für Bitbucket Pipelines ein?

Registrieren Sie den Runner zunächst im passenden Repository- oder Workspace-Kontext und prüfen Sie anschließend die vom Unternehmen festgelegten Labels. Danach ordnen Sie jeden Build-Schritt über runs-on einem geeigneten Knotenpool zu. Die Freigabe erfolgt erst, wenn ein Testlauf Routing, Protokollierung, Arbeitsbereichsbereinigung und den Zugriff auf benötigte Werkzeuge nachweisbar bestätigt.

Eignet sich ein Bitbucket macOS Runner für die Veröffentlichung einer iOS-App?

Ja, sofern der Knoten als vertrauenswürdige Produktionsumgebung behandelt wird. Für iOS-Veröffentlichungen müssen Xcode-Werkzeuge, Apple-Zertifikate, Provisioning-Profile, Keychain-Zugriffe und Berechtigungen getrennt kontrolliert werden. Ein gemeinsam genutzter Runner ist dafür ungeeignet, wenn fremde oder nicht vollständig geprüfte Jobs auf denselben Host gelangen können.

Wie trennen Sie mehrere Repositorys auf einem Workspace Runner?

Verlassen Sie sich nicht auf den Workspace-Geltungsbereich allein. Verwenden Sie getrennte Labels und Knotenpools für unterschiedliche Vertrauensstufen. Testen Sie anschließend mit absichtlich falschen Labels, ob ein Job abgewiesen oder in eine weniger privilegierte Umgebung geleitet wird. Schlüssel, Keychains, Caches und Artefakte dürfen nicht zwischen diesen Pools erreichbar sein.

Wie werden Arbeitsbereich und Zugangsdaten nach einem macOS-Build bereinigt?

Löschen Sie Quelldateien, Derived Data, temporäre Dateien, Caches und verbliebene Prozesse. Entfernen Sie importierte Zertifikate und Profile aus der verwendeten Keychain oder zerstören Sie den Knoten nach einem sensiblen Job. Dokumentieren Sie getrennt, was Bitbucket automatisch bereinigt und was Ihr Team per Skript oder durch Knotenrotation übernimmt.

Was tun Sie, wenn ein selbst gehosteter Bitbucket Runner offline geht?

Prüfen Sie zuerst Prozessstatus, lokale Logs, Netzwerkverbindung und den Zustand des Mac. Der Wiederanlauf muss nach einem Prozessabbruch, einer kontrollierten Neustartaktion und einem Netzwerkverlust getestet werden. Ein Knoten darf erst wieder Produktionsjobs annehmen, wenn Registrierung, Labels, Werkzeugversionen und Bereinigungszustand automatisch oder nachweisbar manuell bestätigt sind.

Ein eigener Mac im Büro oder Rechenzentrum gibt Ihnen zwar direkte Kontrolle, verursacht aber Anschaffung, Ersatzplanung, Wartung, Stromversorgung und manuelle Wiederherstellung. Ein ungetrennter Shared Runner senkt die Einstiegshürde, vergrößert jedoch den Schadensradius und erschwert den Nachweis sauberer Signaturumgebungen. Remote gemietete Macs lösen diese Punkte nicht automatisch, können Ihnen aber für Pilotphasen und variable Kapazität eine kontrollierbare Alternative bieten. Wenn Sie nach der Abnahme temporäre oder zusätzliche Mac-Kapazität benötigen, können Sie bei CALMVPS einen passenden Mac-Zugang anfragen. Entscheidend bleibt, dass Sie die Plattform zuerst mit einer nicht produktiven Pipeline prüfen und erst nach belegter Isolation, Bereinigung und Wiederherstellung schrittweise ausweiten.