Vous êtes libres de le tester. Tous les retours sont bienvenues
Le plugin fonctionne en 2 étapes :
la première sert de veille via genie. Quand une nouvelle version corrective est détectée, ce job réalise les préparatifs et déclenche le décompte de 10 minutes vers l’étape suivante ci-dessous. Pendant la période d’attente, un message qui apparait sur l’ensemble des sessions connectées pour que les utilisateurs aient le temps de terminer.
la phase d’exécution s’occupe des modifications au plus vite. Tout le monde est déconnecté juste avant la mise à jour (afin de survivre à une disparition de ‹ ecrire/ ›)
Il y a plein de vérifications qui sont faites dans les deux étapes pour réduire le risque d’erreurs.
Pendant la mise à jour le site est remplacé alors par une page statique qui se rafraichit toutes les 15 secondes.
A la fin de la mise à jour, une sonde vérifie que le site est bien en 200 après mise à jour. Elle rétabli l’ancienne version si ce n’est pas le cas.
Ensuite, les personnes qui étaient connectées sont redirigées vers le formulaire de login.
Précision importante : la version actuelle ne prend pas en compte les changements de structure des données. C’est pour cela qu’elle ne prend pas en charge les versions antérieures à SPIP 4.4.18
Pour tester sur votre hébergement, installez un site jetable dans une version 4.4.x quelque part (sous-répertoire, etc.), installez et activez le plugin. La phase de veille a une période de 4h. Vous pouvez la déclencher avec la flèche en face de l’action « auto-update » dans la liste des taches de fond.
J’ai fait une proposition d’architecture il y a un peu plus d’une semaine
et précisé ensuite que je travaillais à une proposition, ce que j’ai pris le temps de faire hors repo plublic avec @marcimat car cela avait des implications sur le processus de release et des choix techniques associés.
On (l’équipe du core) va donc proposer un plugin pour assurer les mises à jour automatique de SPIP à partir cette proposition technique.
Malgré cela tu as choisi de continuer tête baissée à nous vibe coder un truc sans discussion et sans aucune considération pour l’impact sur le projet.
On a déjà du mal à trouver suffisamment de personnes impliquées et qui participent, ça va vraiment pas aider de faire cet appel à test de prototype alors même qu’on va releaser un plugin du core qui sera également à tester.
Du coup les gens vont tester quelque chose, on saura pas quoi, on aura des remontées de bug incompréhensibles parce qu’en fait ils ont installé l’autre plugin, ça va être un capharnaüm et un fiasco complet, et on aura pas avancé.
Merci de ton aide, vraiment, et celle de ton bot IA qui a produit tout ça.
L’un n’empêche pas l’autre. Mon plugin ne vise pas à être intégré à SPIP. Il pourra facilement s’adapter à ta proposition d’architecture qui améliorera les mises à jour. Et si le futur mécanisme officiel peut s’inspirer de concepts que j’aurais prototypé ici, alors tant mieux ^^
Quand j’avais posé le ticket il y a 12 an,s je ne pensais pas pouvoir m’investir beaucoup. Et j’ai effectivement fait une pause pendant 10 ans, pour redécouvrir le ticket il y a 3 jours
Cela fait juste quelques jours que je recommence à me remettre sur le code d’outils pour SPIP, et ce grâce à des IA. C’est ce qui me permet de casser la barrière technique. Les briques de base que j’ai créé au début permettent de ne pas faire n’importe quoi en partant toujours des tests. Ce n’est pas du vibe coding déstructuré.
Je suis content de pouvoir de nouveau proposer et tester des choses.
Mais là tu réponds à côté de ce qui est très précisément pointé : tu peux tester autant de chose que tu veux en vibe codant comme un foufou, pour des choses où seul toi travailles dessus.
Mais SI SI l’un empêche l’autre, c’est justement le problème central, si tu te mets à demander publiquement des tests pour exactement la même fonctionnalité qui est en train d’être développée et supportée officiellement par l’équipe du core. En faisant ça, tu désorganises les tests utilisateurs et le peu de temps que l’équipe arrive à y consacrer déjà.
Quand une chose est publiquement annoncée dans un ticket ou sur les forums comme en train d’être conçue et/ou codée, le but c’est de travailler en commun, en se parlant, pas chacun dans son coin.
Perso, je ne testerai rien qui vienne d’une initiative personnelle et isolée. Utilisateur de SPIP depuis 10 ans, j’ai une totale confiance dans l’équipe du Core. De plus, l’utilisation de l’IA agit comme un repoussoir certain.
Je n’ai pas vu celles de la version officielle en cours de développement. Mais je suis convaincu que je fais ma mise à jour autrement. Avec d’autres contrôles. Avec d’autres contraintes (absurdes certainement) que j’ai imposé.
Par exemple, j’utilise un mécanisme de sonde qui est déconnecté de SPIP pour vérifier l’absence d’erreur 500. Je propose un retour arrière en cas d’échec. Je modifie provisoirement les fichiers index.php et spip.php pour que tous les visiteurs soient sur une page d’attente. C’est quelques outils qui n’existent pas dans l’approche officielle via spip_loader.php
Ce plugin est une source d’expérimentation. Si ça peut profiter à d’autres plugins, tant mieux. Cela m’a permis de détecter quelques problèmes liés à SPIP que je vais bientôt remonter. Donc je ne pense pas que ce soit inutile
Mais justement, pourquoi fais-tu tout ça tout seul dans ton coin au lieu de venir échanger avec l’équipe du core (qui en appelle à de nouvelles énergies depuis longtemps) et faire ENSEMBLE alors même que tu as eu l’info plus tôt dans la semaine ?
Je suis d’accord avec ce qui est dit plus haut, en agissant de la sorte, tu apportes de la confusion à celles et ceux qui n’auront pas tout suivi et qui ne feront pas la différence entre ton plugin et celui de l’équipe du core.
Cette remarque et URL est particulièrement intéressante, puisque dedans on voit
des gens t’’ont fait des retours aussitôt auquel tu n’as pas répondu…
1b) ou en fait tu as peut être répondu (ou ton agent automatiquement ?) en éditant le descriptif du ticket, et uniquement ça (on n’a pas de notification directe de cela en plus) et en répondant aux questions dedans… vraiment pas pratique… pas dans les discussions ouvertes
tu as fait des modifications dessus il y a 3 semaines sans relancer non plus pour regarder de nouveau la PR…
tu peux aussi faire des relances de temps en temps sur les PR en cours, notamment si tu penses que les points indiqués ont été traités ou n’ont pas lieu de l’être
Malgré cela je suis d’accord,
il y a des PR présentes qui ne sont toujours pas traitées ou fermées automatiquement avec le temps… l’étendue de la zone est grande, les gens ne voient pas toujours tout ou n’ont pas toujours le temps
tu peux faire ton autoupdate évidemment (peut être trouver un nom / préfixe différent pour éviter les confusions avec celui de Cédric ?), en espérant que tu le maintiennes dans le temps : je vois bien que ton plugin a infiniment plus de tests automatisés par exemple que celui de Cédric, vu que lui en a zéro ; c’est un des avantages indéniable des IA…
qui plus est je doute que Cédric ait envie de voir de l’IA jouer avec son plugin en PR pour le moment…
Le problème que je vois là avec toutes les IA branchées sur SPIP 4, c’est qu’elles vont y faire «des miracles» avec un code pas du tout adapté… C’était un des objectifs de SPIP 5 de moderniser et découper ce code à différents endroits, notamment pour les tests automatisés ; je vois bien que tout cela va être très compliqué en coordination au vu des dernières PR et tickets récents entièrement postés en IA, sans interactions avec les humain·es derrière ;
(je me demande s’il ne faudrait pas mettre des notes d’intentions dans un AGENTS.md sur spip/spip d’ailleurs de la dev a minima…)
nous avons tester le plugin, la mise a jour de spip 4.4.24 s’est faite sur deux à 3 jours sur une vingtaine de site, ce qui me gène c’est que j’ai pas beaucoup de notifications, si il pouvait y avoir un endroit où mettre une adresse mail, histoire de savoir qui est mis a jour, ce serait bien…
Ah non, il ne faut pas tester ce plugin
Il faut essayer « autoupdate » plugin en cours de test qui sera possiblement intégré au core prochainement.
Merci.
L’un n’empêche pas l’autre à ce que je sache ; Gilles a bien le droit d’avoir aussi des retours sur son plugin (m’est avis qu’il faudrait lui trouver un autre nom cependant)
Tu devrais le voir dans l’ajout de plugin dans SVP en fait en le cherchant… Sinon il est développé pour l’instant sur spip / autoupdate · GitLab
Nous (ie momo et moi, pour le pic qui accompagne les adhérents utilisateurs de spip - cf. https://le-pic.org) avons testé ce plugin et il fonctionne pas mal du tout. Mais il est clair que lorsque la fonctionnalité sera mûre dans le core c’est ça qu’il faudra utiliser en prod.
C’est vrai que c’est bien d’avoir plein de tests avant la mise à jour, mais je pense que cette fonctionnalité devrait être dissociée de la mise à jour proprement dite. Par exemple le fait de tester que /tmp n’est pas exporté est super-intéressant, et nous a permis de détecter plusieurs sites mal configurés. Oui mais est-ce que ça ne devrait plutôt être incorporé à un outil spécialisé ? spip-check, ou un outil spécialisé dans le test de configuration ?
Bon, cela dit les message sont écrits en jargon incompréhensible (sauf par les IAs ? ) Par exemple un de nos sites renvoie ce message qui n’aide pas vraiment: « Sonde finale en échec : statut 0. » On fait quoi quand on a ça ?
En tous cas c’est vraiment très cool d’avoir cette fonctionnalité dans spip et si elle est incorporée à spip (quelque soit l’origine du code) c’est vraiment super !
Utilisez si possible le plugin de l’équipe de dev de SPIP, il sera sans doute plus stable car testé sur de nombreux sites.
Rappel d’installation du plugin « autoupdate » : Page « Gestion des plugins » de l’espace privé, onglet « Ajouter un plugin », recherchez « autoupdate », puis installez. L’avantage d’est qu’il sera automatiquement à jour si vous ajoutez (et paramétrez) le plugin « majPlugins ».
Et si vous voulez malgré tout tester mon plugin officiellement non officiel, et voulez des modifications, il suffit d’ajouter un ticket sur la page des tickets du plugin
Bonjour
Nous avons testé AutoUpdate v1.1.0 sur un site très gros (beaucoup de pages avec beaucoup d’images). Je précise que le plugin de Gilles a été inopérant sur ce site web (« Sonde finale en échec : statut 0. »).
Lors de la mise à jour il est apparu un message sur le backoffice disant:
Fonction public_composer() introuvable
Fonction public_composer_dist() introuvable
Mais la mise à jour a tout de même été réalisée (bravo AutoUpdate !), pas trace de message d’erreur ni de warning dans les logs.
Depuis, tout fonctionne
) Par exemple un de nos sites renvoie ce message qui n’aide pas vraiment: « Sonde finale en échec : statut 0. » On fait quoi quand on a ça ?