Hier finden Sie Hilfe zu Verbindungen, Xcode-Builds, CI/CD-Runnern, Speicher, Netzwerk und Abrechnung auf exklusiven physischen Mac-Knoten. Führen Sie zuerst die Basisprüfungen der Reihe nach durch. Wenn das Problem bleibt, senden Sie Bestellung, Umgebung und bereinigte Logs gemeinsam ein.
Ändern Sie nicht gleichzeitig Netzwerk, Systemversion und Build-Konfiguration. Ändern Sie immer nur eine Variable und bewahren Sie den ursprünglichen Fehlertext sowie den Zeitpunkt auf. Nur so lässt sich die Ursache der Verbindungs-, Umgebungs- oder Projektebene zuordnen.
Prüfen Sie zuerst Knotenadresse, Port, Benutzername und Zugangsdaten. Kontrollieren Sie anschließend lokale Netzwerkbeschränkungen, Verschlüsselungsoptionen des Clients und den Sitzungsstatus. Verwenden Sie alte Zugangsdaten nicht wiederholt.
Verbindungsschritte öffnenNotieren Sie die Fehlerphase und prüfen Sie danach Speicherplatz, Xcode- und SDK-Version, Sperrdatei der Abhängigkeiten, Signiermaterial und das vollständige Build-Log. Bewahren Sie vor allem den ersten tatsächlichen Fehler auf.
Reihenfolge der Build-Diagnose anzeigenPrüfen Sie Runner-Prozess, Registrierungsstatus, passende Labels, Berechtigungen des Arbeitsverzeichnisses und das Parallelitätslimit. Ein online angezeigter Runner erfüllt nicht automatisch die Labels des aktuellen Auftrags.
Runner-Konfiguration prüfenTrennen Sie Quellcode, Abhängigkeits-Cache, DerivedData, Archive und Auslieferungsartefakte nach ihrer Nutzung. Exportieren Sie benötigte Dateien zuerst und bereinigen Sie anschließend gezielt Verzeichnisse. Löschen Sie keine Daten mit unklarem Zweck direkt.
Häufige Fragen zum SpeicherDokumentieren Sie vor einer Migration den aktuellen Knoten, die Hostingregion des Repositorys, den Standort der Hauptnutzer und die Richtung großer Dateiübertragungen. Erstellen Sie vorab unabhängige Kopien von Code und Build-Artefakten.
Knoten und Netzwerk vergleichenHalten Sie Bestellnummer, gewählte Konfiguration, Abrechnungszeitraum, Zahlungsart und den im Dashboard angezeigten Status bereit. Senden Sie nur die Transaktionskennung, niemals vollständige Kartendaten oder private Schlüssel.
Abrechnungsticket im Dashboard einreichenFühren Sie beim ersten Zugriff zuerst Verbindungs- und Sicherheitsprüfungen durch und konfigurieren Sie danach die Entwicklungsumgebung. So lassen sich System- und Abhängigkeitsprobleme trennen und später leichter reproduzieren.
Prüfen Sie den zur Bestellung gehörenden Knoten, Serveradresse, Port, Benutzernamen und temporäre Zugangsdaten. Die Verbindungsdaten sind ausschließlich für aktuell autorisierte Mitglieder bestimmt und dürfen nicht über Chatverläufe oder öffentliche Dokumente weitergegeben werden.
Abschlusskriterium: Eine Sitzung lässt sich stabil aufbauen und der richtige, zur Bestellung gehörende Knoten ist bestätigt.Aktualisieren Sie nach dem ersten Zugriff die temporären Zugangsdaten und erstellen Sie Systemkonten gemäß der Berechtigungsrichtlinie des Teams. Administratorrechte erhalten nur Mitglieder, die Tools installieren oder Dienste anpassen müssen.
Abschlusskriterium: Temporäre Zugangsdaten werden nicht mehr verwendet; Alltags- und Administratorkonten sind klar getrennt.Dokumentieren Sie macOS-Version, Chip, verfügbaren Speicher, Xcode-Version, Pfad der Kommandozeilentools und Ziel-SDK. Das Team sollte diese Angaben in sein Build- und Betriebshandbuch übernehmen.
Abschlusskriterium: Unterschiede zwischen lokalen und Cloud-Builds lassen sich mit denselben Versionsangaben erklären.Installieren Sie Abhängigkeiten anhand der Sperrdatei des Projekts, richten Sie ein separates Cache-Verzeichnis ein und registrieren Sie anschließend den self-hosted runner. Verwenden Sie beim ersten Auftrag eine geringe Parallelität, um Signierung, Archivierung und Upload zu prüfen.
Abschlusskriterium: Ein minimaler Build-Auftrag lässt sich wiederholt ausführen und hinterlässt vollständige Logs.Rufen Sie zunächst einen nachweislich baubaren Commit ab und führen Sie nur Installation der Abhängigkeiten, Kompilierung und Archivierung aus. Fügen Sie parallele Aufträge, Cache-Wiederherstellung und Bereitstellung erst nach erfolgreicher Prüfung hinzu.
Vorbereitung der VerbindungsprüfungBuild-Probleme betreffen meist sechs Ebenen: Speicherplatz, Signierung, Versionen, Abhängigkeiten, Logs und Parallelität. Führen Sie nach jeder Ebene denselben Commit erneut aus und dokumentieren Sie die Änderung.
Prüfen Sie getrennt den freien Speicher des Systemvolumes, DerivedData, Abhängigkeits-Cache, Archivverzeichnis und Exportartefakte. Bei Platzmangel sichern Sie notwendige Artefakte und bereinigen anschließend gezielt Verzeichnisse.
Prüfen Sie, ob Team, gültiges Zertifikat, Ziel des Bereitstellungsprofils und Bundle Identifier übereinstimmen. Fügen Sie privaten Signierschlüssel niemals Logs oder Tickets bei.
Dokumentieren Sie den tatsächlich für den Build verwendeten Xcode-Pfad. Stellen Sie sicher, dass die Kommandozeilentools nicht auf eine andere Version zeigen, und prüfen Sie, ob das erforderliche Ziel-SDK vorhanden ist.
Vergleichen Sie den Cache mit der Sperrdatei auf Aktualität. Versuchen Sie zunächst einen sauberen Build ohne Cache-Wiederherstellung. Funktioniert dieser, stellen Sie die Abhängigkeits-Caches einzeln wieder her, um die Abweichung zu finden.
Bewahren Sie ausgeführten Befehl, Exit-Code und ersten tatsächlichen Fehler auf. Der letzte Bildschirmausschnitt allein lässt häufig frühere Fehler aus; fügen Sie bereinigte Logs vom Start bis zum Ende bei.
Reduzieren Sie die Parallelität auf einen einzelnen Auftrag und beobachten Sie Speicher-, Festplatten- und Netzwerkauslastung. Ist ein Einzelauftrag erfolgreich, ein paralleler Lauf jedoch nicht, erhöhen Sie die Parallelität schrittweise, bis die stabile Grenze erreicht ist.
Wenn die sechs Prüfebenen keine Ursache ergeben, senden Sie fehlgeschlagenen Commit, ausgeführten Befehl, Umgebungsversionen, Exit-Code und bereinigte Logs ein.
Build-Ticket einreichenExklusive physische Knoten eignen sich als self-hosted runner. Ein stabiler Betrieb setzt jedoch eine klare Registrierungsstrategie, Labels, Dienstverwaltung, Cache-Grenzen und Berechtigungssteuerung voraus.
Verwenden Sie für jeden Knoten einen eindeutigen Runner-Namen und dokumentieren Sie Repository oder Organisation, Registrierungsbereich, Arbeitsverzeichnis und Dienstkonto. Widerrufen Sie bei einer Migration zuerst die alte Registrierung.
Labels sollten stabile Fakten wie Chiparchitektur, Xcode-Hauptversion, Knotenregion und Zweck ausdrücken. Vermeiden Sie schwer wartbare Kombinationen aus temporären Projektnamen.
Betreiben Sie den Runner als verwalteten Dienst und dokumentieren Sie Startmethode sowie Log-Speicherort. Prüfen Sie nach einem Neustart, ob der Dienst automatisch wiederhergestellt wird, und testen Sie einen Minimalauftrag.
Verwalten Sie Abhängigkeiten, DerivedData und Archive in getrennten Verzeichnissen und legen Sie Bereinigungsschwellen fest. Der Cache beschleunigt Abläufe, darf aber weder die einzige Projektkopie noch ein dauerhaftes Auslieferungsarchiv sein.
Das reguläre Build-Konto erhält nur die für den Auftrag erforderlichen Verzeichnis- und Befehlsrechte. Für Toolinstallation, Systemänderungen und Dienstverwaltung sind Administratorrechte zu verwenden.
Dienstprozess → Gültigkeit der Registrierung → passende Labels → Berechtigungen des Arbeitsverzeichnisses → externe Verbindung → Auftragswarteschlange der Plattform.
Einheitliche Begriffe im Ticket verhindern, dass physischer Knoten, Remote-Sitzung, Runner und Build-Cache als derselbe Fehlergegenstand behandelt werden.
VMArm bietet 5 Knotenregionen: Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und den Westen der USA. Vergleichen Sie Remote-Bedienung, Repository-Abrufe, Abhängigkeitsdownloads und Artefakt-Uploads gemeinsam.
Geeignet für Teams in Südostasien sowie Repositorys und Bereitstellungsketten mit Schwerpunkt in Südostasien.
Geeignet für Teams in Japan und Ostasien; ermöglicht eine gute Verbindung aus Remote-Desktop-Bedienung und Zugriff auf regionale Build-Ressourcen.
Geeignet für Entwicklerteams, Abhängigkeitsspiegel und Bereitstellungsprozesse in Südkorea und Nordostasien.
Geeignet für kollaborierende Teams in Südchina und Südostasien. Testen Sie vor der Auswahl sowohl Repository- als auch Remote-Sitzungsverbindungen.
Geeignet für Teams an der US-Westküste sowie Projekte mit Repositorys, Abhängigkeitsquellen oder Bereitstellungssystemen in Nordamerika.
| Prüfobjekt | Messung | Zu dokumentieren | Bewertungsschwerpunkt |
|---|---|---|---|
| Remote-Sitzung | Verbindung und Interaktion während und außerhalb der Arbeitszeit getrennt testen | Lokales Netzwerk, Knoten, Clientversion, Zeitpunkt | Dauerhafte Störung oder Schwankung zu bestimmten Zeiten |
| Code-Repository | Klonen, Abrufen und Submodule mit demselben Repository und Commit testen | Repositoryregion, Dauer, fehlgeschlagener Befehl, Exit-Code | Langsamer Verbindungsaufbau oder langsame Übertragung großer Dateien |
| Abhängigkeitsdownload | Einmalige vollständige Abhängigkeitsauflösung ohne Cache ausführen | Abhängigkeitsquelle, Paketmanager-Version, fehlerhaftes Paket, Anzahl der Wiederholungen | Einzelne Quelle gestört oder gesamte Bandbreite beeinträchtigt |
| Artefakt-Upload | Übertragung mit bereinigten Testdateien gleicher Größe vergleichen | Dateigröße, Zielregion, Start- und Endzeit | Einfluss von Upload-Strecke, Zieldienst oder Dateigröße |
Ein Ticket soll nicht nur belegen, dass ein Problem besteht, sondern die Zuordnung zu Bestellung, Knoten, Zeitpunkt und fehlgeschlagenem Schritt ermöglichen.
Zur Bestätigung von Konfiguration, Abrechnungszeitraum und Bereitstellungsdaten.
Geben Sie Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong oder den Westen der USA an.
Geben Sie den Zeitpunkt einschließlich Zeitzone an und teilen Sie mit, ob der Fehler reproduzierbar ist.
Geben Sie die vollständige macOS-Version an, nicht nur den Namen der Hauptversion.
Geben Sie außerdem die von den tatsächlichen Kommandozeilentools verwendete Version und den Pfad an.
Beginnen Sie mit dem funktionierenden Zustand und beschreiben Sie jeden Klick oder Befehl in der tatsächlichen Reihenfolge.
Behalten Sie Fehlerkontext und Exit-Code bei und entfernen Sie Tokens, private Schlüssel sowie andere vertrauliche Informationen.
Melden Sie sich an, wählen Sie die betreffende Bestellung und senden Sie das Problem ein. Bestell- und Knotenkontext sind dann vollständig und eignen sich für Verbindungs-, Build-, Migrations- und Abrechnungsprobleme.
Zum DashboardWenn Sie noch nicht bestellt haben, nennen Sie Zweck, Zielkonfiguration, Anzahl paralleler Builds, bevorzugte Region und geplanten Starttermin.
Kontaktmöglichkeiten anzeigenEntfernen Sie vor dem Einreichen Zugriffstokens, private Signierschlüssel, vollständige Zahlungsdaten und andere vertrauliche Inhalte. Informationen zur Datenverarbeitung finden Sie in derDatenschutzerklärung.
Die Reihenfolge der Bearbeitung richtet sich nach Auswirkung und Reproduzierbarkeit. Der Support kümmert sich um Bereitstellung, Verbindung, Umgebung und Bestellung; die Projektverantwortlichen müssen die Geschäftslogik bestätigen.
Bewerten Sie den Umfang anhand nicht möglicher Verbindungen, vollständig blockierter Builds, einzelner fehlerhafter Aufträge oder allgemeiner Fragen und prüfen Sie mögliche Alternativen.
Wir bestätigen Bestellung, Knoten, Zeitpunkt, Umgebung und Logs. Fehlen Angaben, werden die benötigten Felder ausdrücklich genannt.
Wir nennen aktuelle Prüfebene, bereits ausgeschlossene Ursachen, nächste Validierung und erforderliche Tests, damit keine Schritte ohne zusätzlichen Erkenntnisgewinn wiederholt werden.
Das Ticket geht in den Abschlussprozess über, sobald das Problem behoben, Ursache und Vermeidung erklärt oder eine Projektkonfiguration festgestellt und eine umsetzbare Prüfrichtung genannt wurde.
Wählen Sie VMArm M4 Core oder VMArm M4 Plus und anschließend eine Region: Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong oder Westen der USA. Maßgeblich ist die Verfügbarkeit, die das Dashboard in Echtzeit meldet.