J’ai presque terminé un plugin de mise à jour automatique de SPIP en tâche de fond. Pour des raisons de stabilité et de possibilité de rollback en cas d’échec, je dois m’assurer qu’il n’y a pas de changement de model dans la base de données.
A cause de cela, le plugin ne fonctionne pas avec SPIP4.4.16.
Est-ce qu’on est certain que les prochaines versions de maintenances n’entraineront pas de modification de la base de données ?
C’est très bien de faire aussi des trucs dans ton coin… Tu aurais peut être pu échanger dessus avant car Cédric aussi s’est lancé dans quelque chose Mise à jour automatique de SPIP (#3348) · Issues · spip / spip · GitLab ; (cela dit Cédric n’est pas très loquace dessus non plus), et on en a plutôt discuté de ça pour l’instant dans spip-security :
il a commencé des choses et un plugin,
j’ai adapté en conséquence un certain nombre de nos outils de release (spip-archives, supported-versions) pour que ces nouveautés ne nous prennent pas plus de temps supplémentaire manuellement
il se base sur des zips partiels (et rollback), que l’api v3 de spip_loader.api fournie spip_loader.api/3 (et fournira surtout pour les prochains) ;
il n’a pas de souci à avoir une maj de BDD en montée de version a priori
On ne peut pas garantir que des mises à jour de patch n’auront pas de mises à jour de base de données, c’est un problème pour les rollback surtout, mais il n’y a pas de miracle de ce côté.
Pour répondre à la question de départ : ben si dans une mise à jour Z il peut parfaitement y avoir des modifications de base de données. Ça a même été le cas très récemment dans l’une des versions récentes.
Je vais me retenir de dire le fond de ma pensée pour pas qu’on se fâche, mais produire du code au kilomètre dans son coin a jamais été d’une grande aide pour contribuer au projet, Gilles, et c’est pas en produisant encore plus vite et plus de code avec un agent IA que ça va plus nous aider.
Ce dont on a besoin c’est de gens impliqués, qui font ensemble et qui sont là pour maintenir le code dans le temps. De ce point de vue l’enjeu c’est de produire moins de code.
Ça serait pas mal que tu fasses une pause et que tu prennes le temps de réfléchir un peu là dessus…
Je termine mon module et je reviens vers ton analyse. Désolé, je me suis lancé sur mon chantier en solo, avec une urgence qui était d’avoir des modules que je puisse poser partout et qui soient capables de revenir en arrière en cas d’échec.
ok, je vais en tenir compte pour le traitement de la restauration en cas d’échec (site qui ne répond pas en 200 après mise à jour pour faire simple). A la limite ça m’arrange car le changement dans la base intervenu en SPIP 4.18 me bloque pour faire des mises à jour de maintenance sur des versions plus anciennes.
Je le sais, c’est pour cela que je reste pour le moment dans mon coin. C’est parce que je ne connais pas assez bien le code de SPIP que je suis obligé de faire appel à ce type d’outils (et de créer des skills pour que ces logiciels ne pondent pas n’importe quoi, tout en évitant de scanner sans cesse le code source en mode grep).
Promis, bientôt je ferai du code qui sera plus facile à relire manuellement.
Je vais commencer par apporter quelques éléments à ta réflexion sur une fonctionnalité de mise à jour auto qui puisse être intégrée dans le core de SPIP.
