Commandes ne retournant pas de code d'erreur
La quasi totalité des commandes ne retournent pas de code d'erreur. On ne peut donc pas savoir si elles se sont correctement exécutées dans un contexte automatisé.
Sauf erreur de lecture de ma part, voici les commandes qui retournent bien un code d'erreur :
- core:installer
- php:run
- sql:convert:to:mysql
Les commandes qui retournent un code d'erreur dans certains cas, mais pas toujours :
- core:telecharger (il y a des «exit» sans argument dans certains cas)
- sql:dump:restore
De plus, php:eval initialise une variable $return, mais ne la retourne pas.
Toutes les autres commandes ne font qu'afficher des choses en rouge, sans jamais changer le code de retour.
Exemple d'effet de bord : en ce moment il est impossible d'ajouter un dépot de plugin (cf spip/spip#4914 (closed) ). J'ai un script qui appelle successivement core:dl, core:prepare, core:install, spv:depoter, plus installe des plugins. Ça plante à partir de l'étape svp:depoter, et je me retrouve donc avec des installations incomplètes. Dans un contexte 100% automatisé, c'est assez gênant de ne pas avoir de remontée d'erreur.
PS : je n'ai fait que lire le code de spip-cli à la recherche de «return» et «exit». Il se peut que certains chemins de codes lèvent des exceptions (et retournent donc bien des codes d'erreur).
PPS: je ne suis pas familier de Symfony. Je vois qu'il y a aussi des «return false» parfois. Je ne sais pas si c'est bien interprété comme un échec.