Von der Verbindung bis zur Artefaktprüfung

Deinen Cloud-Mac in den Build-Prozess integrieren

Dies ist keine theoretische Übersicht, sondern ein Schritt-für-Schritt-Ablauf. Prüfe zunächst Identität und Sicherheit des exklusiven physischen Knotens, richte dann Xcode, Signaturmaterial und Automatisierung ein. Bei Problemen sammelst du Netzwerkdaten und Build-Logs nach einem einheitlichen Schema.

5 Kategorien Support-Themen
6 Schritte Automatisierte Build-Kette
2 Arten Nachverfolgbare Kontaktwege
Cloud-Mac jetzt mieten Runner-M4-Konfiguration ansehen
RUNNER SUPPORT ROUTE MAC-01
01
Übergabe und Prüfung Verbindungsparameter, Host-Fingerabdruck, Erstpasswort
Vorbereiten
02
Build-Umgebung vorbereiten Xcode, Toolchain, Signaturmaterial, Verzeichnisse
Konfigurieren
03
Automatisierte Aufgaben ausführen Auschecken, Caching, Archivieren, Exportieren, Prüfen
Ausführen
04
Diagnosedaten sammeln Knoten, Bestellung, Zeit, Befehle und vollständige Ausgabe
Analysieren
Jede Diagnose beginnt mit reproduzierbaren Eingaben
Erstverbindung

Knotenidentität und Sicherheit in fünf Schritten prüfen

RunnerVM stellt einen exklusiven physischen Mac mini bereit, keine virtuelle Maschine. Bei der ersten Nutzung geht es nicht darum, möglichst schnell Befehle auszuführen, sondern das bestellte Gerät zu bestätigen und den anfänglichen Zugriff durch eigene sichere Einstellungen zu ersetzen.

  1. 01

    Übergabedaten in der Konsole abrufen

    Prüfe Bestellkennung, Knotenregion, Verbindungsadresse, SSH-Port, VNC-Parameter und anfänglichen Benutzernamen. Vollständige Zugangsdaten nicht per Chat weiterleiten; im Team nur die für die ausführende Person erforderlichen Felder teilen.

  2. 02

    Zuerst den Host-Fingerabdruck dokumentieren

    Vergleiche den in der Konsole angezeigten Host-Fingerabdruck Zeichen für Zeichen mit dem ersten SSH-Hinweis. Bei abweichendem Algorithmus oder Hash die Verbindung abbrechen und ein Ticket erstellen; known_hosts-Einträge nicht löschen, um die Warnung zu umgehen.

  3. 03

    SSH-Verbindung über die Kommandozeile herstellen

    Verbinde dich mit Host, Port und Benutzername aus der Bestellung. Nach der Anmeldung zuerst sw_vers,uname -m und hostname, und schreibe Systemversion, Apple-Silicon-Architektur und Gerätenamen in den Übergabedatensatz.

  4. 04

    Bei Bedarf VNC-Remote-Desktop einrichten

    Trage im lokalen VNC-Client Adresse, Port und Passwort aus der Konsole ein. Verwende zunächst die Standardauflösung, um Tastatur, Zeiger und Fensterskalierung zu prüfen. Erhöhe die Auflösung erst nach stabiler Sitzung.

  5. 05

    Passwort aktualisieren und Berechtigungen beschränken

    Ändere das Erstpasswort sofort, prüfe SSH-Schlüssel und Administratorrechte und behalte nur erforderliche Zugriffe. Stelle SSH- und VNC-Sitzungen anschließend erneut her, bevor du Projekt- oder Signaturmaterial importierst.

Beispiel für die Befehlsausführung

Von der Verbindungsprüfung bis zur Archiv-Ausgabe

Hier folgt die Reihenfolge eines typischen Builds mit SSH-, xcodebuild- und fastlane-Ausgaben. Host, Arbeitsbereich, Scheme, Exportkonfiguration und Lane müssen durch die echten Projektwerte ersetzt werden; nicht einfach kopieren und die Eignung für jedes Repository voraussetzen.

  • Zuerst das Verbindungsziel bestätigen, dann in das Projektverzeichnis wechseln.
  • Für Archive ein aufgabeneindeutiges Verzeichnis verwenden, damit parallele Jobs sich nicht überschreiben.
  • Die vollständige Standardausgabe und den Exit-Code speichern, nicht nur die letzte Zeile.
runner-build-session zsh
Knoten verbinden SSH 
$ ssh -p 22 runner@10.0.0.12
Host key fingerprint: SHA256:…
$ sw_vers
ProductName: macOS
$ uname -m
arm64
Archiv erstellen XCODEBUILD 
$ xcodebuild archive \
-workspace RunnerApp.xcworkspace \
-scheme RunnerApp \
-archivePath build/RunnerApp.xcarchive
** ARCHIVE SUCCEEDED **
Automatisierten Ablauf ausführen FASTLANE 
$ bundle exec fastlane ios build
[08:42:16]: Resolving signing settings
[08:43:02]: Archive completed
[08:43:11]: Export verified
[08:43:11]: fastlane finished successfully
Beispielbefehle müssen an Arbeitsbereich, Scheme, Signaturverfahren und Verzeichnisstruktur des Projekts angepasst werden.
Umgebung vorbereiten

Xcode, Signaturmaterial und Verzeichnisse prüfbar machen

Umgebungsprobleme hängen meist nicht daran, ob sich Xcode öffnen lässt, sondern daran, ob Auswahl der grafischen Oberfläche, Kommandozeilenpfad, Projektdefinition und Signaturkontext übereinstimmen. Prüfe sie in der folgenden Reihenfolge, um Toolchain- und Projektprobleme schneller zu unterscheiden.

01

Xcode-Version und Pfad prüfen

Führe xcodebuild -version und xcode-select -p aus. Sind mehrere Versionen installiert, kläre zuerst die Projektanforderung und wechsle dann das Entwicklerverzeichnis, damit Oberfläche und Automatisierung nicht unterschiedliche Versionen verwenden.

02

Command Line Tools prüfen

Führe xcrun --find xcodebuild, xcrun simctl list und eine unsignierte Projektauflösung aus. Fehlt ein Tool oder ist die SDK-Liste fehlerhaft, repariere zuerst die Toolchain und ändere nicht direkt Projektdateien.

03

Aufgabenbezogenen Signaturschlüsselbund einrichten

Lege die von der Automatisierung verwendeten Zertifikate in einem separaten Schlüsselbund ab und definiere klare Entsperrschritte mit minimalen Zugriffsrechten. Passwörter nicht in Repository, Skriptparametern oder Build-Logs speichern.

04

Zertifikate und Provisioning-Profile importieren

Dokumentiere Zertifikatsname, Gültigkeit, Team-ID und UUID des Provisioning-Profils und prüfe, ob die Bundle Identifier zur Zielkonfiguration passt. Prüfe nach dem Import mit security find-identity -v -p codesigning die verfügbaren Identitäten.

05

Build-Verzeichnisse planen

Trenne Quellcode, Dependency-Cache, DerivedData, Archive, Export und Logs. Verwende je Job einen eindeutigen Archivpfad; gemeinsame Caches dürfen nur wiederherstellbare Inhalte enthalten und kein Signaturmaterial.

Automatisierte Builds

Einen erfolgreichen Build in sechs reproduzierbare Phasen verwandeln

Automatisierung bedeutet nicht, lokale Skripte einfach auf einen Remote-Host zu verschieben. Eingaben, Umgebung, Signatur und Ausgaben müssen reproduzierbar sein. Jede Phase sollte einen klaren Datensatz erzeugen, damit der Fehlerort erkennbar bleibt.

  1. 01

    Feste Codeversion auschecken

    Verwende einen Commit-Hash oder geschützten Tag statt eines sich weiterbewegenden Branch-Kopfes. Dokumentiere Submodul-Versionen, Git-LFS-Status und den sauberen Repository-Zustand.

    git checkout --detach <commit>
  2. 02

    Dependency-Cache wiederherstellen und prüfen

    Der Cache-Schlüssel muss mindestens Lockfile-Hash, Toolversion und Architektur enthalten. Bei einem Cache-Miss normal installieren; ein Cache-Treffer ist keine Voraussetzung für einen erfolgreichen Build.

    bundle check || bundle install
  3. 03

    Signaturkonfiguration laden

    Entsperre den aufgabenbezogenen Schlüsselbund, importiere das passende Provisioning-Profil und prüfe verfügbare Signaturidentitäten. Schlüssel und Passwörter dürfen nie in die Standardausgabe gelangen.

    security find-identity -v -p codesigning
  4. 04

    Archive ausführen

    Arbeitsbereich, Scheme, Configuration, Destination und Archivpfad explizit angeben. Vollständiges Log und xcodebuild-Exit-Code speichern.

    xcodebuild archive …
  5. 05

    Lieferartefakte exportieren

    Exportkonfiguration versionieren, aber keine Geheimnisse aufnehmen. Export- und Archivverzeichnis trennen, damit erneute Läufe das ursprüngliche xcarchive nicht überschreiben.

    xcodebuild -exportArchive …
  6. 06

    Ergebnis prüfen und registrieren

    Dateiexistenz, Größe, Hash, Signaturinformationen und Exit-Code prüfen und Artefaktkennung mit Commit, Xcode-Version und Logpfad verknüpfen.

    shasum -a 256 build-output
Remote-Desktop

VNC für grafische Aufgaben, lange Jobs in unabhängigen Prozessen

Der Remote-Desktop eignet sich für die erste grafische Einrichtung, die Kontrolle des Xcode-Status und Aufgaben mit visueller Prüfung. Ein Build darf nicht davon abhängen, dass das lokale VNC-Fenster verbunden bleibt.

Verbindungsparameter

Verwende ausschließlich Adresse, Port, Benutzername und Passwort aus der Konsole. Auch bei unterstützten Verbindungsprofilen das Passwort nicht in synchronisierbaren Klartextdateien speichern.

Auflösung anpassen

Bei der ersten Verbindung die Standardgröße verwenden. Nach stabiler Interaktion die Auflösung schrittweise erhöhen; bei Verzögerungen zunächst Farbtiefe und Bildgröße reduzieren und anschließend den Netzwerkpfad prüfen.

Sitzung sperren

Sperre die grafische Sitzung vor dem Verlassen des Geräts; das Schließen des VNC-Clients ersetzt keine Bildschirmsperre. Beim Schichtwechsel nicht mehr benötigte Zugriffsrechte entziehen.

Aufgaben nach der Trennung

Dauerhafte Builds sollten in einem CI-Runner, launchd, tmux oder einer anderen wiederaufnehmbaren Sitzung laufen. Einmal aktiv trennen und prüfen, ob Aufgabe und Logs weiterlaufen.

Übergabeformular für Remote-Sitzungen VNC / SSH
Vor dem Start Knoten- und Sitzungsidentität prüfen

Bestellregion, Gerätenamen und aktuell angemeldeten Benutzer bestätigen.

Während der Ausführung Aufgabe in separates Log schreiben

Nicht allein anhand der Bildschirmausgabe beurteilen, ob der Build noch läuft.

Beim Verlassen Sitzung sperren und Hintergrundaufgabe prüfen

Nach der Trennung per SSH Prozesse, Log-Zuwachs und Exit-Status prüfen.

Nach der Übergabe Temporäre Berechtigungen entziehen

Temporäre öffentliche Schlüssel, Einmaldateien und nicht mehr benötigte Zugangsdaten entfernen.

Netzwerk und Latenz

Konnektivität, Route, Namensauflösung und Port gemeinsam dokumentieren

Bei Netzwerkproblemen muss klar sein, von wo, zu welchem Zeitpunkt, auf welches Ziel zugegriffen wurde und welche vollständige Ausgabe entstand. Ein Screenshot oder „Die Verbindung ist langsam“ unterscheidet lokales Netzwerk, internationale Route, DNS, Portregeln und Zielstatus nicht.

PING

Grundlegende Round-Trip-Zeit und Paketverlust prüfen

Eine feste Anzahl an Paketen senden und minimale, durchschnittliche sowie maximale Latenz und Paketverlust dokumentieren. Eine einzelne Antwort repräsentiert nicht die Qualität der gesamten Verbindung.

ping -c 20 target-host
TRACEROUTE

Ort der Routenänderung prüfen

Im betroffenen Quellnetz ausführen und alle Hops speichern. Keine Antwort eines Zwischenknotens bedeutet nicht automatisch einen Abbruch; die Erreichbarkeit des Endziels muss einbezogen werden.

traceroute target-host
DNS

Auflösungsergebnis und Dauer prüfen

Aktuellen DNS-Server, zurückgegebene Adressen und Abfragedauer dokumentieren. Bei unterschiedlichen Ergebnissen aus verschiedenen Netzen beide Ausgaben einreichen und Ergebnisse nicht manuell verändern.

dig target-host
PORT

Erreichbarkeit des Zielports prüfen

SSH-Port oder den tatsächlich vom Projekt verwendeten Port separat testen. Eine erfolgreiche Verbindung bestätigt nur die TCP-Erreichbarkeit, nicht Authentifizierung oder Anwendungsprotokoll.

nc -vz target-host 22
Diagnosepaket für Support-Tickets

Diese fünf Angaben müssen enthalten sein

NET-CHECK
Zeitpunkt des Problems
Lokales Datum, Uhrzeit, Zeitzone und Dauer angeben.
Quellstandort
Quellknoten, Büro- oder Heimnetz und Netzbetreiber nennen.
Zielinformationen
Bestellkennung, Knotenregion, Zielhost und Port angeben.
Vollständige Ausgabe
Originalergebnisse von Ping, Traceroute, DNS- und Portprüfung beifügen.
Vergleichsergebnisse
Wenn möglich, denselben Test aus einem anderen Netz oder zu einem anderen Zeitpunkt ergänzen.

Vor dem Einreichen Passwörter, private Schlüssel, Tokens und Geschäftsdaten entfernen, aber Zeitstempel, Fehlercodes, Routen-Hops und Befehlsparameter beibehalten.

Support-Eskalation

Problem zuerst eingrenzen, dann ein nachvollziehbares Ticket einreichen

Fragen vor dem Kauf, allgemeine Beratung und nicht bestellbezogene Informationen können per E-Mail gesendet werden. Bei Knoten-, Build-, Verbindungs- oder Abrechnungsproblemen in der Konsole ein Ticket erstellen, damit Bestellung und Bearbeitungsstatus verknüpft bleiben.

  1. 01

    Passenden Leitfaden suchen und ausführen

    Wähle einen Ablauf für Erstverbindung, Umgebung, Automatisierung oder Netzwerkdiagnose. Dokumentiere ausgeführte Schritte, Befehle, Ergebnisse und das erstmalige Auftreten der Abweichung.

  2. 02

    Minimale Reproduktionsdaten zusammenstellen

    Bestellkennung, Knotenregion, Zeitpunkt, Reproduktionsschritte, erwartetes und tatsächliches Ergebnis sowie vollständige, anonymisierte Logs bereitstellen. Bei Build-Problemen zusätzlich Commit und Xcode-Version nennen.

  3. 03

    Ticket in der Konsole erstellen

    Wähle die passendste Kategorie und füge Logs als Anhang oder Codeblock ein. Ein Ticket sollte sich auf ein Problem konzentrieren; Netzwerk-, Build- und Abrechnungsprobleme nicht vermischen.

  4. 04

    Fortschritt im ursprünglichen Ticket ergänzen

    Nach einem erneuten Test im bestehenden Ticket mit neuen Zeitpunkten, Befehlen und Ausgaben antworten. Auch dringende Fälle über die Konsole verfolgen und keine mehrfachen identischen Tickets erstellen.

Bestellung zuordnen

Ticket in der Konsole

Geeignet für Verbindungsfehler, Knotenprobleme, Build-Umgebungen, Abrechnungsklärungen und Fälle mit weiterem Nachverfolgungsbedarf. Tickets können Bestellungen zugeordnet werden und bewahren die vollständige Bearbeitungszeitleiste.

  • Bestellkennung und Knotenregion
  • Problemzeitpunkt mit Zeitzone
  • Reproduktionsschritte und vollständige Fehlerausgabe
  • Ausgeführte Diagnosebefehle und Ergebnisse
In der Konsole ein Ticket erstellen
Allgemeine Beratung

Support-E-Mail senden

Geeignet für Auswahlberatung vor dem Kauf, Prozessfragen, Sicherheitsmeldungen und nicht knotenbezogene Informationen. Kategorie im Betreff nennen und im Text keine Passwörter oder Schlüssel einfügen.

support@runnervm.com
Vorlage benötigt

Zuerst strukturierte Angaben erstellen

Die Kontaktseite führt Pflichtangaben für Fragen vor dem Kauf, Technik, Abrechnung und Sicherheit auf und eignet sich zur Prüfung vor dem E-Mail-Versand.

Kontaktinformationen ansehen
Häufige Fragen

Vor der Diagnose diese Grenzen klären

Die folgenden Antworten unterscheiden Geräteübergabe, Verbindungsarten, Build-Aufgaben und Supportmaterial und vermeiden wiederholte Versuche in der falschen Richtung.

Stellt RunnerVM virtuelle Instanzen bereit?

Nein. Die Bestellung bezieht sich auf einen exklusiven physischen Mac-mini-Knoten mit Runner-M4-Ausstattung: Mac Mini M4, 16GB RAM, 256GB SSD. Die Remote-Verbindung ist lediglich eine Zugriffsmethode und macht den Dienst nicht zu einer gemeinsam genutzten virtuellen Ressource.

Läuft der Build nach dem Trennen von VNC weiter?

Das hängt vom Startmechanismus ab. CI-Runner, launchd, tmux oder unabhängige Hintergrundprozesse benötigen in der Regel kein VNC-Fenster; interaktive Aufgaben, die direkt an eine grafische Sitzung gebunden sind, können vom Sitzungsstatus abhängen. Vor dem produktiven Einsatz einmal aktiv trennen und Prozesse, Logs sowie Exit-Status prüfen.

Was muss ich vor der Erstverbindung vorbereiten?

Bereite nutzbare SSH- und VNC-Clients, eine teaminterne Methode zur Zugangsdatenverwaltung, die erforderliche Xcode-Version, eine Liste des Signaturmaterials und einen nicht im Repository gespeicherten Geheimnisverwaltungsprozess vor. Nach Erhalt der Übergabedaten zuerst Host-Fingerabdruck und Geräteidentität prüfen.

Ändert die Diagnose den Abrechnungszeitraum der Bestellung?

Nein, nicht automatisch. Runner M4 kann tage-, wochen-, monats- oder quartalsweise bestellt werden; Zeitraum und Bearbeitungsstatus richten sich nach der Konsolendokumentation. Für eine konkrete Bestellung in der Konsole ein zugeordnetes Ticket erstellen.

Was muss ich nach Abschluss der Aufgabe bereinigen?

Zuerst benötigte Archive, Artefakte und anonymisierte Logs exportieren, danach Quellcode-Arbeitsbereich, temporären Signaturschlüsselbund, Provisioning-Profile, temporäre öffentliche Schlüssel, Zugriffstokens und vertrauliche Projektdaten aus Caches bereinigen. Klartextzugangsdaten nicht in Shell-Verlauf oder Skriptparametern hinterlassen.

Wie entscheide ich mich für den passenden Knoten?

Teste zunächst aus dem tatsächlichen Büro- oder CI-Netz Latenz und Route zur Zielregion und berücksichtige anschließend Teamzeitzone und Artefaktübertragungsrichtung. Runner M4 ist in Singapur, Tokio, Seoul, Hongkong und an der US-Ostküste bestellbar; die aktuelle Verfügbarkeit zeigt die Konsole.

Nächster Build

Mit einem prüfbaren Cloud-Mac starten

Wähle Runner M4 und die Zielregion. Nach der Bestellung prüfst du die Verbindung, bereitest die Toolchain vor und führst den ersten reproduzierbaren Build nach den Schritten dieser Seite aus.

Cloud-Mac jetzt mieten RunnerVM-Support kontaktieren