Teilen über


Fehlerhafte Builds

Wichtig

Visual Studio App Center wird am 31. März 2025 eingestellt. Sie können Visual Studio App Center zwar weiterhin verwenden, bis es vollständig eingestellt ist, es gibt jedoch mehrere empfohlene Alternativen, zu denen Sie möglicherweise eine Migration in Erwägung ziehen.

Erfahren Sie mehr über Supportzeitpläne und Alternativen.

Es gibt verschiedene Gründe, warum bei Ihrem Build ein Fehler aufgetreten sein könnte, der für Ihr Projekt einzigartig sein könnte. Eine effiziente Möglichkeit zum Diagnostizieren von Buildfehlern ist in der Regel der Vergleich mit einem funktionierenden Build. Dieser Prozess kann Variablen minimieren und relevante Bedingungen für Ihr Szenario identifizieren.

Wenn das Erstellen lokal, aber nicht im App Center funktioniert

In der Regel liegt dieses Problem an nicht committeten Dateien, abweichenden Tools oder nicht wiederhergestellten Abhängigkeiten. Um dies zu überprüfen, können Sie einen vollständigen Git-Klon Ihres Projekts in einen neuen Ordner erstellen. Kompilieren Sie ihn dann zum Vergleich mit derselben Konfiguration wie im App Center.

  1. Öffnen Sie Ihre Terminal- oder Befehlszeileneingabeaufforderung, und geben Sie Folgendes ein: mkdir appcenter-test
  2. Ändern Sie dann die Verzeichnisse: cd appcenter-test
  3. Klonen Sie Ihr Repository mit: git clone -b <branch> <remote_repo>
  4. Starten Sie das frisch geklonte Projekt in Ihrer lokalen IDE oder Befehlszeile.
  5. Vergleichen Sie den in App Center ausgeführten Buildbefehl mit dem lokal ausgeführten Befehl.
  6. Vergleichen Sie die Versionen der tools, die Sie lokal verwenden, mit unseren Cloud Build Machines

Dateien mit geänderten Dateinamen oder Speicherorten werden ignoriert.

Builds ignorieren möglicherweise eine Schlüsseldatei, die kürzlich verschoben oder umbenannt wurde. Wählen Sie in der Buildkonfiguration Speichern oder Speichern & Build aus. Beide Optionen indiziert Ihre Repositorystruktur neu und aktualisiert die Builddefinition.

Bekannte Ursachen sind das Verschieben oder Umbenennen von Buildskripts & nuget.config Dateien.

Vergleichen verschiedener Builds in App Center

Nachverfolgen von Änderungen in Ihren Buildeinstellungen

Sie können Ihre Branchkonfiguration aufzeichnen, indem Sie diese API-Methode aufrufen: https://openapi.appcenter.ms/#/build/branchConfigurations_get

Die API lässt die Aufzeichnung vergangener Konfigurationen nicht direkt zu. Sie können diesen Befehl jedoch mit einem benutzerdefinierten Buildskript ausführen, damit Ihre Builds automatisch die aktuelle Konfiguration aufzeichnen, wenn sie ausgeführt werden.

Nachverfolgen von Änderungen in App Center Cloud Build Machines

Wie ihre Buildeinstellungen können Sie die aktuellen Tools überprüfen, indem Sie dieses Dokument lesen: Cloud Build Machines.

Sie können jedoch aufzeichnen, welche dieser Tools für einen bestimmten Build verfügbar sind, indem Sie diesen Befehl in einem Buildskript ausführen:

eval cat $HOME/systeminfo.md

Einige Verzweigungen funktionieren, während andere fehlschlagen

Versuchen Sie, nach Unterschieden in den Buildeinstellungen oder dem commitierten Code zwischen Branches zu suchen. Wenn der Build nach einem bestimmten Commit auf demselben Branch konsistent fehlschlägt, lohnt es sich, zu überprüfen, welche Änderungen im fehlerhaften Commit vorgenommen wurden.

Builds schlagen zeitweilig fehl

Ein Build kann ohne Änderung des Quellcodes oder der Buildeinstellungen fehlschlagen. Beispiel:

  • Verschiedene Versionen von Paketen wiederhergestellt
  • Externe Dienste reagieren nicht
  • Einzelne Aufgaben im Buildzeitpunkt
  • Durchführen weiterer Operationen

Überprüfen Sie, ob der Fehler für den Build konsistent ist, wenn die Fehler auftreten.

Isolieren und Interpretieren von Fehlermeldungen

Automatische Fehlermarkierung

App Center Build versucht automatisch, häufige Fehlermeldungen oder nützliche Ausgaben hervorzuheben, um sie sichtbarer zu machen. Häufig können Hinweise im primären Fehler, der Protokollierung vor oder der Protokollierung nachher gefunden werden. Diese App wird von den Projekteinstellungen & Buildkonfiguration signiert. Daher protokolliert der Android-Jarsigner einen Fehler:

Screenshot: hervorgehobener Fehler

jarsigner: unable to sign jar: java.util.zip.ZipException: invalid entry compressed size (expected 13274 but got 13651 bytes)
##[error]Error: /usr/bin/jarsigner failed with return code: 1
##[error]Return code: 1

Ausführlichere Analyse

Wenn Sie keine relevanten Fehlermeldungen finden, besteht der nächste Schritt darin, die Buildprotokolle herunterzuladen, die Sie auf der Standard Buildseite ausführen können. Öffnen Sie den Ordner mit dem Namen logs_n > Build , und Sie sehen eine Liste mit separaten Protokolldateien in numerischer Reihenfolge. Beispiel:

  • 1_Intialize job.txt
  • 2_Checkout.txt
  • 3_Tag build.txt
  • Durchführen weiterer Operationen

Protokolle werden basierend auf den Hauptphasen Ihres Builds nummeriert. Die meisten Buildfehler führen dazu, dass Phasen übersprungen werden, und das zugehörige Protokoll ausgelassen wird:

  • (Schritte 1-9)...
  • 10_Pre Build Script.txt
  • 11_Build Xamarin.Android project.txt
  • 12_Sign APK.txt
  • 15_Post Build Script.txt
  • 20_Post Checkout.txt
  • 21_Finalize Job.txt

Phase 13 wurde zuerst übersprungen, sodass Phase 12 ein guter Ausgangspunkt ist. Spätere Phasen wurden ebenfalls übersprungen, aber sie sind wahrscheinlich weniger relevant.

Identifizieren korrelierter Commits

Auf der Build-Benutzeroberfläche können Sie die Commitnachricht und den Hash anzeigen, der für Ihren aktuellen Build gilt. Sie können dieses Feature verwenden, um Buildergebnisse nachzuverfolgen und änderungen im Quellcode zu korrelieren.

Sie können Commitnachrichten & Hashes anzeigen, indem Sie zu Appcenter.ms -> [Organisationsname] -> [App-Name] -> Build -> [Branch-Name] -> [Build-Number] wechseln.

Prototyp-URL: https://appcenter.ms/orgs/[ORG-NAME]/apps/[APP-NAME]/build/branches/[BRANCH-NAME]/builds/[BUILD-NUMBER]

Screenshot: Commit & Hash aus der Quelle

Oben in den Informationen für den Build sehen Sie den Namen und den abgekürzten Hash des Commits. Im Screenshot:

  • Erhöhen von Xamarin.UITest von 3.0.5 auf 3.0.6
  • Commit 328ff115

Wenn Sie auf den gekürzten Hash klicken, wird das verknüpfte Repository im gleichen Commit geöffnet: https://github.com/microsoft/appcenter-Xamarin.UITest-Demo/commit/328ff115cb67280f7bdc70074ff605c8962470e4

Nächste Schritte

Hier sind einige Optionen, um Ihr Problem weiter zu recherchieren:

Support kontaktieren

Melden Sie sich an https://appcenter.ms/apps , und klicken Sie auf das Chatsymbol in der unteren rechten Ecke des Bildschirms. Um optimale Ergebnisse zu erzielen, empfiehlt es sich, das Ticket mit folgendem Zu öffnen:

  • Eine Zusammenfassung Ihrer Beobachtungen
  • Details und Zitate Ihrer Recherchen zum Thema
  • URLs für fehlerhafte Builds, einschließlich wichtiger Informationen wie App-Name & Build-ID
  • URLs zum Übergeben von Builds zum Vergleich mit den Fehlern (falls zutreffend)