Für Einsteiger, Release Engineers und CI/CD-Verantwortliche. Gib einen Befehl, einen Fehlerauszug oder einen Aufgabennamen ein, grenze das Problem ein und prüfe anschließend die erwartete Ausgabe.
Aktuell werden 8 Einstiege angezeigt.
Jeder Einstieg nennt Prüfobjekte, Befehle oder Beobachtungswerte. Die Filter ändern nur die Einstiege unten; die vollständigen Abschnitte bleiben sichtbar.
Verbindungsdaten aus der Konsole abrufen und SSH, grafische Oberfläche, Passwort und Zeitzone prüfen.
Xcode-Toolchain, Signaturdaten, Archivpfad und Regeln zur Aufbewahrung von Build-Artefakten prüfen.
Plattformregistrierung, Knoten-Tags, Parallelitätsgrenzen und Arbeitsverzeichnisse je Aufgabe unterscheiden.
Interaktionsverzögerungen schrittweise nach Auflösung, Farben, Bildrate und Netzwerkschwankungen eingrenzen.
Bedeutung von Knoten, Runner, Cache und Signatur-Assets vereinheitlichen und Missverständnisse vermeiden.
Netzwerk-, Festplatten-, Xcode- und Signaturprobleme in Befehle, Erwartungen und Fehlerpfade gliedern.
Region, Zeitpunkt, Aufgabennummer und bereinigte Logs angeben, damit der Support den Ablauf reproduzieren kann.
Wiederaufbaubare Caches, Archivresultate und aufzubewahrende Release-Artefakte unterscheiden.
Kürze den Fehlertext oder suche nach einem Befehlsnamen, zum Beispiel xcodebuild und df -h oder ping.
Maßgeblich sind die aktuellen Instanzdetails in der Konsole. Adressen und Zugangsdaten nicht aus alten Tickets, Chatverläufen oder früheren Skripten übernehmen.
Zuerst eine stabile Verbindung herstellen, dann Passwort und Zeitzone prüfen. Netzwerk, Auflösung und Authentifizierung nicht gleichzeitig ändern, sonst lässt sich die Ursache nicht zuordnen.
Region, Hostadresse, Port, Benutzername und Instanzstatus prüfen. Zugangsdaten nur in einem kontrollierten Passwortmanager speichern, nicht im Repository oder Build-Log.
Ausführen ssh -v user@host Damit werden Auflösung, Handshake und Authentifizierungsphasen angezeigt. Bei einem Timeout vor dem Verbindungsaufbau zuerst lokales Netzwerk und Port prüfen; bei Authentifizierungsfehlern Benutzername und aktuelle Zugangsdaten kontrollieren.
Für Arbeiten in der Xcode-Oberfläche VNC oder Bildschirmfreigabe verwenden. Zunächst Auflösung und Farben unverändert lassen und Tastatur, Maus sowie Zwischenablage prüfen, bevor die Bildqualität angepasst wird.
Initialpasswort ändern, date und systemsetup -gettimezone ausführen, um Zeit und Zeitzone zu prüfen und sicherzustellen, dass das Projektverzeichnis dem aktuellen Aufgabenbenutzer gehört.
Ein reproduzierbarer iOS-Build erfordert eine feste Toolchain, einen definierten Projekteinstieg, Signatur-Assets, Archivparameter und Exportpfad. „Build fehlgeschlagen“ reicht für eine Prüfung nicht aus.
Zuerst xcode-select -p und xcodebuild -versionausführen, um Entwicklerverzeichnis und Xcode-Version zu bestätigen, die das Skript tatsächlich verwendet. Nach einem Versionswechsel beide Befehle erneut ausführen und nicht den Titel des Terminalfensters heranziehen.
Der Zugriff auf Signatur-Assets ist nach Projekt und Umgebung zu begrenzen. Nach dem Import mit security find-identity -v -p codesigning verfügbare Identitäten prüfen und Zertifikatspasswörter nicht im Pipeline-Log ausgeben.
Das Skript muss Workspace oder Project, ein freigegebenes Scheme, Configuration und -archivePathexplizit angeben. Auf dem Build-Rechner nicht von einer temporären Auswahl der letzten Xcode-Sitzung abhängen.
Mit -exportArchive und einer versionskontrollierten Exportkonfiguration Artefakte erzeugen. Archive, Exportresultate, Build-Logs und Commit-ID speichern; bei Fehlern auch bereinigte Diagnoseinformationen aufbewahren.
xcodebuild \
-workspace App.xcworkspace \
-scheme App \
-configuration Release \
-archivePath "$PWD/output/App.xcarchive" \
clean archiveOakVM-Knoten sind dedizierte physische Rechner, keine virtuellen Maschinen. Parallelität wird durch zusätzliche dedizierte Knoten erweitert; auch auf demselben Knoten müssen Warteschlange, Tags und Arbeitsverzeichnisse klar abgegrenzt sein.
runs-on präzise zugeordnet; keine mehrdeutigen allgemeinen Tags verwenden.Isolierungsgrundlage:Projektverzeichnisse, Build-Cache, Signatur-Assets und Artefaktverzeichnisse getrennt verwalten. Nicht routinemäßig den gesamten Knoten leeren und keine zwei Projekte dieselben beschreibbaren Signaturverzeichnisse verwenden lassen.
Subjektive Verzögerungen bei VNC und Bildschirmfreigabe müssen nicht durch die Rechenlast des Knotens verursacht werden. Tests in fester Reihenfolge unterscheiden Codierlast, lokale Netzwerkschwankungen und Konkurrenz durch Hintergrundaufgaben.
Die Bildschirmauflösung zunächst auf die niedrigste für die aktuelle Aufgabe erforderliche Stufe setzen und ungenutzte zusätzliche Anzeigebereiche deaktivieren. Wird die Reaktion deutlich besser, liegt die Ursache eher in der zu codierenden Bildmenge.
Videos, Animationsvorschauen und kontinuierlich aktualisierte Überwachungsfenster pausieren. Beim Build unnötige Simulatoransichten schließen und prüfen, ob statische Bearbeitung wieder stabil läuft.
Für Codebearbeitung und Releases ist meist keine hohe Bildrate nötig. Zuerst auf Eingabereaktion und klare Schrift achten, dann die Darstellung schrittweise flüssiger machen.
Am Knoten kontinuierliche Kurzzeit-Latenztests ausführen und Schwankungen sowie Paketverlust beachten, nicht nur den niedrigsten Einzelwert. Nach einem Wechsel des lokalen Netzwerks mit derselben Stichprobengröße erneut testen.
Pro Aufgabe nur eine hauptverantwortliche Person bedienen lassen; andere Teammitglieder über Build-Logs und Artefaktnachweise einbeziehen. Gleichzeitige Bedienung der grafischen Oberfläche erhöht Kontextkonflikte.
Die folgenden Begriffe werden auf OakVM-Seiten, in der Konsole und im Support verwendet. Sie beschreiben Bereitstellungsform und Workflow und stellen keine Empfehlung durch Drittplattformen dar.
Zuerst den ursprünglichen Exit-Code und den ersten relevanten Fehler sichern, erst danach reparieren. Viele Bereinigungsbefehle nacheinander können den Fehlerzustand zerstören und einen Abhängigkeitsfehler fälschlich als Knotenfehler erscheinen lassen.
| Prüfobjekt | Befehl oder Aktion | Erwartetes Ergebnis | Fehlerpfad |
|---|---|---|---|
| Netzwerkauflösung und Erreichbarkeit | ping -c 20 hostssh -v user@host |
Adressauflösung konsistent; keine anhaltenden Paketverluste; SSH erreicht Handshake und Authentifizierung. | Bei Auflösungsfehlern Adresse prüfen; bei Timeout vor dem Verbindungsaufbau lokale Verbindung wechseln und erneut testen; bei Authentifizierungsfehlern nur aktuellen Benutzernamen und Zugangsdaten prüfen. |
| Festplatte und Build-Speicher | df -hdu -sh ~/Library/Developer/Xcode/DerivedData |
Das Zielvolume bietet ausreichend Platz für Quellcode, Abhängigkeiten, Archive und Exportresultate; die Cache-Größe liegt innerhalb des Teamlimits. | Zuerst aufzubewahrende Artefakte verschieben, dann wiederaufbaubare projektbezogene Caches löschen; Archivverzeichnisse unbekannter Herkunft nicht direkt entfernen. |
| Xcode-Toolchain | xcode-select -pxcodebuild -version |
Entwicklerverzeichnis und Version stimmen mit der Pipeline-Dokumentation überein; der Befehl wird erfolgreich ausgeführt. | Bei einem Pfadfehler die Toolchain explizit wechseln; bei abweichender Version Aufgabe stoppen, um nicht vergleichbare Archive zu erzeugen. |
| Projekt und Scheme | xcodebuild -list -workspace App.xcworkspace |
Das Ziel-Scheme ist sichtbar und das für die Automatisierung verwendete Scheme ist freigegeben. | Bei leerer Liste Arbeitsverzeichnis und Dependency-Generierung prüfen; bei fehlendem Scheme Freigabeeinstellungen und Groß-/Kleinschreibung kontrollieren. |
| Signaturidentität | security find-identity -v -p codesigning |
Die für die Aufgabe benötigte Signaturidentität ist sichtbar; die Ausgabe enthält keine durch ungültige oder doppelte Auswahl verursachte Mehrdeutigkeit. | Bei fehlender Identität Importbereich, Schlüsselbundzugriff und Zuordnung zum Provisioning-Profil prüfen; private Schlüssel und Passwörter nicht auf öffentlichen Seiten veröffentlichen. |
| Archiv und Export | Aufbewahren: xcodebuild Exit-Code, Archivpfad und Export-Log. |
Das Archivverzeichnis ist vorhanden; Exportresultat, Commit-ID und Aufgabennummer sind einander zugeordnet. | Mit dem ersten error im Log beginnen; Kompilierung, Signierung, Archivierung und Export getrennt bewerten und den gesamten Fehler nicht anhand der letzten Zeile zusammenfassen. |
Nach einem Netzwerkwechsel die Display-Einstellungen unverändert lassen; nach einem Xcode-Wechsel den Quellcode-Commit unverändert lassen. Nur so sind Ergebnisse vergleichbar.
Spätere Fehler sind oft Folgefehler. Frühesten Fehlerabschnitt, Exit-Code und zugehörigen Befehl dokumentieren.
Host-Zugangsdaten, Tokens, private Schlüssel und sensible Projektpfade entfernen, aber Zeit, Aufgabennummer und Toolversionen beibehalten.
Bestehende Nutzer melden sich vorzugsweise an und reichen über die Konsole ein Ticket ein; bei fehlendem Zugriff eine E-Mail an support@oakvm.com senden. In beiden Fällen keine Zugangsdaten auf öffentlichen Seiten einfügen.
Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong, US-Ostküste oder US-Westküste.
Datum, Uhrzeit und Zeitzone angeben, damit die Knotenlogs abgeglichen werden können.
Eine identifizierbare Nummer aus Bestellung, Instanz oder CI-Aufgabe angeben.
Einstieg, Befehle und den letzten erfolgreichen Schritt vor dem Auftreten des Problems aufführen.
Erwartete und tatsächliche Ausgabe getrennt beschreiben, nicht nur „nicht nutzbar“ schreiben.
Fehlerkontext, Exit-Code und Versionen aufbewahren; Zugangsdaten, Tokens und private Schlüssel entfernen.
Wähle OakVM M4 oder OakVM M4 Pro und konfiguriere die Mietdauer in sechs verfügbaren Knotenregionen. Alle Regionen laufen 365 Tage im Jahr; die tatsächliche Verfügbarkeit liefert die Konsole in Echtzeit.