Auto update migrations

[seballot]

• Convert UpdateHandler to a service MigrationsService, with a new mecanism to perform migration (see below)
• Refactor update action to use the new YesWikiAction style
• Move tools/atoupdate/app to tools/autoupdate/entities
• Adds commands ./yeswicli migrate and ./yeswicli upgrade (package)

To create a new migration : ./yeswicli generate:migration

It will create a new file under migrations folder. You can move this file in a tools folder if you prefer (or in extensions)

Once the file is ready, run ./yeswicli migrate

Each migration completed is stored in the TripleStore, so we run it only once.

The migration is automatically done when upgrading the wiki or an extension via the UI. It's also done when docker start (see entrypoint.sh)

A lot of the migration code that I have moved is obscure to me, I hope I did not do any mistake. The migrations run for me, but I cannot test the result for sure

I have also remove all the outputs from previous migration, leaving only one message if the migration passed or not

Main files to review

• UpdateAction.php
• MigrationsService.php
• the content of migrations folder to see how a migration looks like

Sorry it will be hard to review cause a lot of code have been moved, with some small changes. Also some linting have been applied here and there..

The commit history is not super clean because I have made different tries so come out to the final solution with one file per migration

How to test

For me, using docker, the back ups are not working, preventing to test the update process, so I comment those lines to skip it

[J9rem]

@seballot gros et beau travail.

J'ai identifié dans ta branche de travail quelques points qui pourraient être améliorés pour nous prémunir d'attaques farfelues mais possibles. Est-ce que tu souhaites que je te propose une petite PR vers ta branche pour te proposer ces correctifs ?

[seballot]

oui bien sur ! merci :)

[J9rem]

OK je te prépare ceci d'ici demain.
Je vais regardé au passage ton souci sur les tests que tu as fait remonter. Si je trouve un correctif, je te le proposerai dans une PR dédiée pour que tu puisses mieux identifier les apports de chaque PR.

[J9rem]

@seballot j'essaie de comprendre le code de cette PR pour anticiper les impacts pour les extensions.

• si je comprends bien, post_install est systématiquement lancé que la mise à jour se soit bien passée ou non
• si je comprends bien aussi, le nouveau mécanisme de YesWikiMigrations ne permet de lancer une migration qu'une seule fois (c'est bien comme mécanisme). Toutefois, je vois un petit souci quand on veut faire des actions systématiques après chaque mise à jour (comme réinstaller les formulaires LMS s'ils avaient disparu).
  • Est-ce qu'il serait possible d'émettre en évènement php pour que nous puissions faire ces actions ? $errors = $this->wiki->services->get(\YesWiki\Core\Service\EventDispatcher::class)->yesWikiDispatch('autoupdate.afterInstall',['messages' => $messages]); où $messages est de la classe \YesWiki\AutoUpdate\Entity\Messages (et nous pourrions aussi avoir des évènements comme autoupdate.beforeInstall, autoupdate.afterMigrations autoupdate.beforeMigrations)
  • je peux faire une PR dans ce sens

Qu'en dis-tu ?

[seballot]

oui pas de soucis pour émettre des évènements, bonne idée !

[J9rem]

Je te fais une PR dans ce sens d'ici lundi

[J9rem]

For me, using docker, the back ups are not working, preventing to test the update process, so I comment those lines to skip it

As-tu essayé en mettant dans wakka.config.php : 'preupdate_backup_activated' => false, ?

Parce que pour les tests automatiques en ligne de commande, il n'y a pas l'interface web avec le js pour faire ce qu'il faut pour faire la sauvegarde automatique

[mrflos]

faudra plutot voir si l'on peut rendre les backups auto avant upgrade compatibles cli et docker, j'essayerais de regarder si c'est faisable facilement, sinon je ferai une issue pour que l'on corrige le soucis un jour.

[J9rem]

Normalement, ça vient de l'image docker qui n'ouvre pas les droits d'écriture pour le dossier /private.
Et il faut aussi que l'image docker possède toutes librairies php nécessaires et donne le droit d'utiliser les fonctions php exec sexec, ...
J'avais corrigé ce souci il y a longtemps pour nos scripts github pour les tests. Je ne sais pas si nos images docker ont repris ces corrections.