Damit Ihre Builds weiterlaufen

Prüfen Sie zuerst das aktuelle Entwicklerverzeichnis und die Version und vergewissern Sie sich, dass das gewünschte Xcode installiert ist. Im folgenden Beispiel wird das systemweite Standardverzeichnis auf /Applications/Xcode.appgesetzt. Für eine andere Version ersetzen Sie den Pfad durch den tatsächlichen Speicherort der App.

xcode-select -p
xcodebuild -version
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
xcodebuild -version
xcrun --find swift

Eine systemweite Änderung wirkt sich auf alle danach gestarteten Aufgaben aus. Wenn verschiedene Pipelines unterschiedliche Versionen benötigen, setzen Sie DEVELOPER_DIRbevorzugt in der jeweiligen Job-Umgebung, statt das globale Verzeichnis wiederholt zwischen Jobs umzuschalten.

DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer \
xcodebuild -list -workspace MyApp.xcworkspace

Listen Sie nach dem Wechsel zunächst die Schemes auf und führen Sie anschließend ein Archive aus. Fehlen Plattformkomponenten oder muss Xcode beim ersten Start eingerichtet werden, initialisieren Sie die Toolchain zuerst in der macOS-Oberfläche und starten Sie danach die Automatisierung erneut.

Sie benötigen einen Zertifikatsexport mit privatem Schlüssel, das zugehörige Passwort und ein Provisioning Profile, das zur App-ID und Verteilungsart passt. Ein Zertifikat ohne passenden privaten Schlüssel reicht in der Regel nicht zum Signieren von Code.

1. Öffnen Sie auf dem macOS-Benutzerkonto, unter dem der Build läuft, die Schlüsselbundverwaltung und importieren Sie das Zertifikat in den Schlüsselbund dieses Benutzers.
2. Klappen Sie das Zertifikat auf und prüfen Sie, ob der passende private Schlüssel vorhanden ist. Mit dem folgenden Befehl können Sie gültige Codesignatur-Identitäten anzeigen.
3. Installieren Sie das Provisioning Profile entsprechend den Anforderungen Ihrer Xcode-Version. Prüfen Sie in den Projekteinstellungen für die Signierung Team, Bundle Identifier und Verteilungsart.
4. Prüfen Sie die Signiereinstellungen für App, Widget und Extension einzeln. Führen Sie anschließend ein Archive aus und verifizieren Sie den Export.

security find-identity -v -p codesigning

Die Schlüsselbundumgebung des CI-Ausführungsbenutzers kann sich von der des Remote-Desktop-Benutzers unterscheiden. Für unbeaufsichtigte Builds müssen Sie den Schlüsselbund im Job entsperren und die nötigen Zugriffsrechte einrichten. Lesen Sie das Passwort aus einer geschützten CI-Variable aus. Speichern Sie es weder im Repository noch in der Befehlsausgabe oder im Ticket.

Wenn ein manueller Build funktioniert, CI aber fehlschlägt, vergleichen Sie zuerst den Ausführungsbenutzer und den Schlüsselbundstatus. Melden Sie Signierfehler mit Zertifikatstyp, Gültigkeitsdauer und bereinigten Fehlermeldungen. Laden Sie weder private Schlüssel noch Zertifikatspasswörter hoch.

Betrachten Sie eine Neuinstallation nicht als Möglichkeit, Dateien zu behalten. Dabei können das System und das Arbeitsverzeichnis gelöscht werden. Klären Sie vor dem Antrag über ein Support-Ticket im Portal den Umfang der Maßnahme und sichern Sie Ihre Daten außerhalb des Nodes. Nach Ende der Mietdauer wird der Node-Datenträger gelöscht; ein abgelaufener Node kann nicht als Quelle zur Wiederherstellung dienen.

Sichern Sie mindestens nicht gepushten Quellcode, Build-Konfigurationen, benötigte Artefakte, Provisioning Profiles und geschütztes Schlüsselmaterial. Caches wie DerivedData und heruntergeladene Abhängigkeiten lassen sich neu erstellen, verlängern aber den ersten Build nach der Wiederherstellung.

Eine abgeschlossene Sicherung ist nicht automatisch wiederherstellbar. Entpacken Sie sie in ein separates Verzeichnis, prüfen Sie Dateianzahl und wichtige Konfigurationen und vergewissern Sie sich, dass sich das letzte Artefakt wiederherstellen lässt. Beenden Sie erst danach die Aufgaben auf dem ursprünglichen Node. Installieren Sie nach der Neuinstallation die Toolchain neu, richten Sie die Signierumgebung wieder ein und registrieren Sie den Runner erneut.

Melden Sie sich mit dem Konto der Bestellung an und prüfen Sie im Portal die Instanz, das Ablaufdatum und die verfügbaren Verlängerungszeiträume. Bezahlen Sie anschließend die angezeigte Rechnung. Maßgeblich für die erfolgreiche Verlängerung und die neue Mietdauer ist die aktuelle Rückmeldung im Portal – nicht ein Zahlungs-Screenshot oder die Anzeige vor dem Schließen des Browsers.

Unterstützt werden USDT-TRC20 sowie Visa, Mastercard und Amex über Stripe. Alle Zahlungen erfolgen in US-Dollar; welche Zahlungsanbieter verfügbar sind, zeigt die Rückmeldung der Backend-Schnittstelle. Prüfen Sie bei einer Zahlung über die Blockchain vorab Netzwerk, Betrag und Empfängerdaten. Nach einer Kartenzahlung kontrollieren Sie die Rechnung im Portal.

Wenn Rechnungs- und Instanzstatus voneinander abweichen, senden Sie Bestellnummer, Rechnungsnummer und Transaktionsreferenz. Versuchen Sie nicht, den Status durch eine erneute Zahlung zu korrigieren, und senden Sie keine vollständige Kartennummer im Ticket. Sichern Sie Artefakte und benötigte Dateien vor Ablauf der Mietzeit – eine Verlängerung ersetzt keine Datensicherung.

Prüfen Sie im Portal zuerst Node-Adresse, Port, Benutzernamen und Instanzstatus. Unterscheiden Sie zwischen Zeitüberschreitung und fehlgeschlagener Anmeldung: Prüfen Sie bei einer Zeitüberschreitung zuerst die Netzwerkerreichbarkeit, bei einem Anmeldefehler Benutzername, Passwort oder Schlüssel. SSH und VNC verwenden unterschiedliche Verbindungsdaten – verwenden Sie nicht denselben Port für beide.

ssh -v -p PORT USER@HOST

Ersetzen Sie PORTdurch die tatsächlichen Angaben, ebensoUSERundHOST Bei einer geänderten Host-Fingerprint-Meldung prüfen Sie die Ursache zuerst über vertrauenswürdige Angaben im Portal oder ein Support-Ticket. Deaktivieren Sie nicht einfach die Prüfung der Host-Identität.

Remote-Desktop eignet sich zum Prüfen der macOS-Oberfläche, des Schlüsselbunds und der Xcode-Einstellungen. SSH eignet sich für Kommandozeile und CI. Entfernen Sie vor dem Senden von Logs sensible Angaben zu Benutzernamen, Adressen und lokalen Pfaden. Belassen Sie nur Fehlertyp und Ablauf.

Prüfen Sie vier Punkte: Ist der Runner online? Stimmen die Job-Labels überein? Darf das Projekt diesen Runner verwenden? Läuft der Prozess mit dem richtigen Benutzer? Eine erfolgreiche Registrierung bestätigt nur die Zuordnung – nicht, dass alle Jobs automatisch diesem Node zugewiesen werden.

Starten Sie zunächst einen Testjob, der nur Toolchain-Informationen ausgibt. Prüfen Sie Ausführungsbenutzer, Verzeichnis und Xcode-Version, bevor Sie Schritte für Abhängigkeiten und Signierung hinzufügen.

whoami
pwd
xcode-select -p
xcodebuild -version
security find-identity -v -p codesigning

Nehmen Sie macOS, Chiparchitektur und Einsatzzweck in die Labels auf und wählen Sie diese in der Projektkonfiguration gezielt aus. Begrenzen Sie bei der ersten Einrichtung die Ausführung auf einen Job. Prüfen Sie, ob Cache, Schlüsselbund und Artefaktverzeichnisse getrennt bleiben, und erhöhen Sie erst dann die Parallelität. Registrierungstoken sind Zugangsdaten und gehören weder in Tickets noch in Build-Logs.

Prüfen Sie zuerst, ob Sie das richtige Workspace, ein geteiltes Scheme und die Release-Konfiguration verwenden. Archive und Simulator-Build folgen unterschiedlichen Abläufen. Prüfen Sie Signierung, Architektur und Exporteinstellungen für das Geräteziel gesondert.

xcodebuild -list -workspace MyApp.xcworkspace
xcodebuild archive \
  -workspace MyApp.xcworkspace \
  -scheme MyApp \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath build/MyApp.xcarchive

Sichern Sie den ersten konkreten Fehler samt Kontext, nicht nur die abschließende Meldung „fehlgeschlagen“. Prüfen Sie Abhängigkeitsinstallation, Skriptphasen, Signierung und Schreibvorgänge auf dem Datenträger getrennt. Verifizieren Sie nach erfolgreichem Archive auch das Exportartefakt: Ein abgeschlossenes Archive ist noch kein Paket zur Verteilung.

Prüfen Sie zuerst die Speicherbelegung und den Status laufender Aufgaben. Unterscheiden Sie dann wiederherstellbare Caches von Artefakten, die Sie behalten müssen. Löschen Sie keine Verzeichnisse, von denen ein laufender Job abhängt, und behandeln Sie Quellcode, Signiermaterial oder noch nicht hochgeladene Archives nicht als Cache.

df -h
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/Archives

Legen Sie getrennte Aufbewahrungsregeln für Cache und Artefakte fest. Nach einer Bereinigung können der erste Build und das Auflösen von Abhängigkeiten länger dauern. Betrachten Sie diesen Build als Kaltstarttest. Wenn der Speicherplatz dauerhaft knapp ist, erfassen Sie zunächst das Wachstum von Projekten und Artefakten und wählen Sie dann ein passenderes Modell oder eine zusätzliche SSD-Option.