Partager via

Échec des builds

  • Article

Important

Visual Studio App Center doit être mis hors service le 31 mars 2025. Bien que vous puissiez continuer à utiliser Visual Studio App Center jusqu’à ce qu’il soit entièrement mis hors service, il existe plusieurs alternatives recommandées vers lesquelles vous pouvez envisager de migrer.

En savoir plus sur les chronologies et les alternatives de support.

Il existe différentes raisons pour lesquelles votre build a pu échouer, qui peuvent être propres à votre projet. En règle générale, un moyen efficace de diagnostiquer les échecs de build consiste à les comparer à une build opérationnelle. Ce processus peut réduire les variables et identifier les conditions pertinentes pour votre scénario.

Si la génération fonctionne localement, mais pas dans App Center

Ce problème est généralement dû à des fichiers non validés, des outils différents ou des dépendances non restaurées. Pour vérifier, vous pouvez effectuer un clonage git complet de votre projet dans un nouveau dossier. Compilez ensuite avec la même configuration qu’App Center à des fins de comparaison.

  1. Ouvrez votre terminal ou votre invite de ligne de commande, puis tapez : mkdir appcenter-test
  2. Modifiez ensuite les répertoires : cd appcenter-test
  3. Clonez votre dépôt avec : git clone -b <branch> <remote_repo>
  4. Lancez le projet fraîchement cloné dans votre IDE local ou votre ligne de commande.
  5. Essayez de comparer la commande de build exécutée dans App Center à la commande exécutée localement.
  6. Comparer les versions des outils que vous utilisez localement avec nos machines de génération cloud

Les fichiers avec des noms de fichiers ou des emplacements modifiés sont ignorés

Les builds peuvent ignorer un fichier de clé qui a été récemment déplacé ou renommé. Essayez de sélectionner Enregistrer ou Enregistrer & Générer dans la configuration de build. L’une ou l’autre option réindexe votre arborescence de référentiel et met à jour la définition de build.

Les causes connues sont le déplacement ou le changement de nom des scripts de build & fichiersnuget.config.

Comparaison de différentes builds dans App Center

Suivi des modifications dans vos paramètres de build

Vous pouvez enregistrer la configuration de votre branche en appelant cette méthode d’API : https://openapi.appcenter.ms/#/build/branchConfigurations_get

L’API n’autorise pas directement l’enregistrement des configurations passées. Toutefois, vous pouvez exécuter cette commande avec un script de build personnalisé afin que vos builds enregistrent automatiquement la configuration actuelle lorsqu’elles s’exécutent.

Suivi des modifications dans les machines de génération cloud App Center

Comme vos paramètres de build, vous pouvez case activée les outils actuels en consultant ce document : Cloud Build Machines.

Toutefois, vous pouvez enregistrer les outils disponibles pour une build particulière en exécutant cette commande dans un script de build :

eval cat $HOME/systeminfo.md

Certaines branches fonctionnent tandis que d’autres échouent

Essayez de vérifier les différences dans les paramètres de build ou le code engagé entre les branches. En outre, si la build commence à échouer constamment après un certain commit sur la même branche, il vaut la peine de vérifier quelles modifications ont été apportées dans la validation ayant échoué.

Les builds échouent par intermittence

Une build peut échouer sans aucune modification du code source ou des paramètres de build. Par exemple :

  • Différentes versions des packages restaurés
  • Les services externes ne répondent pas
  • Tâches individuelles dans le délai d’expiration de la build
  • et ainsi de suite

Essayez de vérifier si l’erreur de la build est cohérente lorsque les échecs se produisent.

Isolation et interprétation des messages d’erreur

Mise en surbrillance automatique des erreurs

App Center Build tente automatiquement de mettre en évidence des messages d’erreur courants ou une sortie utile pour le rendre plus visible. Souvent, des indices se trouvent dans l’erreur primaire, la journalisation avant ou la journalisation ultérieure. Cette application est signée par les paramètres du projet & configuration de build. Par conséquent, le jarsigner Android enregistre une erreur :

Capture d’écran de l’erreur mise en surbrillance

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

Aller plus loin

Si vous ne trouvez pas de messages d’erreur pertinents, l’étape suivante consiste à télécharger les journaux de build, ce que vous pouvez faire à partir de la page de génération main. Ouvrez le dossier nommé logs_n > Build et vous verrez une liste de fichiers journaux distincts répertoriés dans l’ordre numérique. Par exemple :

  • 1_Intialize job.txt
  • 2_Checkout.txt
  • 3_Tag build.txt
  • et ainsi de suite

Les journaux sont numérotés en fonction des principales phases de votre build. La plupart des échecs de build entraînent l’omission des phases et l’omission du journal associé :

  • (Étapes 1 à 9)...
  • 10_Pre Script.txt build Script.txt
  • 11_Build project.txt Xamarin.Android
  • 12_Sign APK.txt
  • 15_Post build Script.txt
  • Checkout.txt de travail 20_Post
  • 21_Finalize Job.txt

La phase 13 a été ignorée en premier, donc la phase 12 est un bon point de départ. Les phases ultérieures ont également été ignorées, mais elles sont moins susceptibles d’être pertinentes.

Identification des commits corrélés

Dans l’interface utilisateur de build, vous pouvez afficher le message de validation et le hachage applicables à votre build actuelle. Vous pouvez utiliser cette fonctionnalité pour suivre et mettre en corrélation les résultats de build avec les modifications apportées à votre code source.

Vous pouvez afficher les messages de validation & hachages en accédant à Appcenter.ms -> [Nom de l’organisation] -> [Nom de l’application] -> Build -> [Nom de la branche] -> [Build-Number]

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

Capture d’écran montrant la validation & hachage à partir de la source

En haut des informations relatives à la build, vous verrez le nom et le hachage abrégé du commit. Dans la capture d’écran :

  • Faire passer Xamarin.UITest de 3.0.5 à 3.0.6
  • Commit 328ff115

Cliquer sur le hachage abrégé ouvre le dépôt lié sur le même commit : https://github.com/microsoft/appcenter-Xamarin.UITest-Demo/commit/328ff115cb67280f7bdc70074ff605c8962470e4

Étapes suivantes

Voici quelques options pour rechercher votre problème plus en détail :

Contact du support

https://appcenter.ms/apps Connectez-vous et cliquez sur l’icône de conversation dans le coin inférieur droit de l’écran. Pour de meilleurs résultats, il est judicieux d’ouvrir le ticket avec :

  • Résumé de vos observations
  • Détails et citations de votre recherche sur la question
  • URL des builds défaillantes, y compris des informations essentielles telles que le nom de l’application & l’ID de build
  • URL des builds de passage à comparer aux échecs (le cas échéant)