La solution AEM pour les tests d’interface utilisateur personnalisés ignorés dans Cloud Manager est due à un package d’archive contextuelle Docker incorrect

Dernière mise à jour : 6 juillet 2026

Si Cloud Manager ignore le test d’interface utilisateur personnalisé même si vos tests s’exécutent localement, l’archive contextuelle Docker de test d’interface utilisateur générée peut être compressée avec les fichiers requis dans un répertoire parent plutôt qu’à la racine de l’archive. La vérification de la structure d’archive et la mise à jour de la configuration de l’assemblage Maven restaurent la détection de test dans Cloud Manager.

Description description

Environnement

Adobe Experience Manager as a Cloud Service

Problème/Symptômes

Ce problème apparaît généralement lorsque Cloud Manager ne peut pas détecter les fichiers d’accord préalable de test de l’interface utilisateur dans l’archive contextuelle Docker générée.

L’étape Tests de l’interface utilisateur personnalisée affiche un message similaire à Les tests de l’interface utilisateur ont été ignorés, car aucun test n’a été trouvé dans votre référentiel de code source.
Vos tests d’interface utilisateur Playwright, Cypress, Selenium ou d’autres s’exécutent localement, mais aucune exécution de test d’interface utilisateur n’apparaît dans Cloud Manager.
Le fichier testing.properties existe dans le référentiel, mais Cloud Manager ignore toujours les tests.
Vous pouvez confirmer le problème en créant le module de tests de l’interface utilisateur et en vérifiant où testing.properties est stocké dans le fichier de *-ui-test-docker-context.tar.gz généré. Exécutez tar -tvf target/*-ui-test-docker-context.tar.gz | grep testing.properties. Si le résultat affiche un chemin tel que some-folder/testing.properties au lieu de testing.properties, l’archive est mal compressée.
Vous pouvez également confirmer la configuration en vérifiant que testing.properties est stocké à côté du fichier pom.xml dans le module de tests de l’interface utilisateur et qu’il contient exactement ui-tests.version=1.

Résolution resolution

Essayez les étapes suivantes pour résoudre le problème :

Vérifiez que le pipeline utilise la branche Git appropriée pour le module de tests de l’interface utilisateur. Le pipeline doit utiliser la branche contenant le module et le testing.properties ui.tests. Confirmez-le dans la configuration du pipeline et dans le résumé de l’exécution du pipeline suivant.
Vérifiez que testing.properties existe à côté du fichier de pom.xml du module de tests de l’interface utilisateur et qu’il contient exactement ui-tests.version=1. Vous devriez voir le fichier dans le module approprié avec la valeur requise. Confirmez-le directement dans le référentiel.
Créez le module de tests de l’interface utilisateur localement afin que l’archive contextuelle Docker soit générée. Vous devriez voir un fichier se terminant par -ui-test-docker-context.tar.gz dans le répertoire du target de modules. Vérifiez que l’archive générée utilise le classificateur ui-test-docker-context.
Inspectez l’archive générée et vérifiez si testing.properties est stocké à la racine de l’archive en exécutant tar -tvf target/*-ui-test-docker-context.tar.gz | grep testing.properties. Vous devriez voir uniquement les testing.properties sans préfixe de dossier parent. Si la sortie affiche un chemin tel que some-folder/testing.properties, l’archive n’est pas compressée correctement. Passez à l’étape suivante.
Mettez à jour assembly-ui-test-docker-context.xml afin que le contexte Docker soit compilé à la racine de l’archive. Assurez-vous que l’assembly conserve <includeBaseDirectory>false</includeBaseDirectory> et inclut des testing.properties avec les fichiers de niveau racine tels que Dockerfile et wait-for-grid.sh. Les fichiers requis doivent être stockés au niveau supérieur de l’archive, et non dans un répertoire de wrapper. Confirmez en reconstruisant le module et en répétant l’inspection d’archive jusqu’à ce que testing.properties apparaisse à la racine.
Validez les modifications apportées au package, poussez-les vers la branche utilisée par le pipeline, puis exécutez à nouveau le pipeline. L’étape Custom UI Testing doit s’exécuter au lieu d’afficher un message d’omission. Confirmez-le dans les détails d’exécution du pipeline et vérifiez que les journaux de test de l’interface utilisateur sont disponibles.
Si les tests sont maintenant détectés mais échouent lors de l’exécution, consultez les journaux de test de l’interface utilisateur à partir de l’exécution du pipeline et corrigez les erreurs liées au test ou à la structure. Cloud Manager doit détecter et exécuter l’image de test avec succès. Confirmez en vérifiant que le pipeline affiche une exécution de test réelle de l’interface utilisateur plutôt qu’une étape ignorée.

Si les symptômes ci-dessous apparaissent et que les étapes de dépannage produisent les résultats ci-dessous, envoyez un ticket au support technique d’Adobe : l’archive affiche testing.properties à la racine, le pipeline utilise la branche appropriée et Cloud Manager continue de signaler qu’aucun test d’interface utilisateur n’a été trouvé.

Incluez la liste d’archivage, le fichier assembly-ui-test-docker-context.xml, les pom.xml du module de tests de l’interface utilisateur et l’URL d’exécution du pipeline lorsque vous contactez l’assistance.

recommendation-more-help

experience-cloud-kcs-help-kbarticles