search

AlliumCepa / webgui

A free open source content management system and web application framework. The most widely deployed mod_perl application on the planet.
http://www.webgui.org/
41 stars 14 forks source link

admin plugin for running upgrades #36

Closed scottwalters closed 5 years ago

scottwalters commented 5 years ago

Kinda silly that this is still done at the shell, and moving the build process to Docker means that it'll be that much harder to just nip over to shell and run something. So, create an admin that does this for us.

testEnvironment.pl, cpanm, wgd would still be needed in the docker image unless the design here radically changes.

Was previously starting to use github as a CDN but not sure how we'd release new versions now.

scottwalters commented 5 years ago

This is the command to run updates:

cd /WebGUI
perl -Ilib /WebGUI/sbin/wgd reset --upgrade  --config-file=webgui.conf --webgui-root=/WebGUI/

Testing changes to Dockerfile now to hopefully get all of the modules built in that things need. Some of the update code was missing a few so I merged in the big list from testEnvironment.pl.

Updates are in /WebGUI/share/upgrades/7.10.24-8.0.0/*.

So far, we've been adding new files without bumping the version. The version stored in the db controls which directory full of updates get run. So if a new update gets added and the version doesn't get bumped, it has to be run manually.

wgd turns around and runs sbin/webgui.pl of all things with some args, --doit --override --skipBackup --skipDelete, and that does the actual work. Guess I probably should have run that directly to save time.

I don't remember, but I think something somewhere temporarily sets the site into maintenance mode while updates are running.

Each wG subversion (X in n.n.X) has updates that go back for a limited number of versions, so if your wG is old, you have to upgrade in steps. Not sure how to handle that. I guess we always give people the latest version if we never delete any of the update files. Not really a problem right now.

Fetching the next code then running updates would then be all of the work needed assuming maintenance mode works right.

Kinda a braindump on the subject in case it is useful.

Also of note, wG7 has had several fixes that haven't yet been forward-ported, and those fixes would include update files for the jump from 7.10.24 to 8.0.0. There may already be a ticket open for forward-porting those fixes.

scottwalters commented 5 years ago

After some more discussion on this:

The Docker images should not attempt to pull new versions of wG in to themselves. That's Doing It Wrong (sorry). Instead, users are expected to fetch a new docker image when they want to upgrade. That docker image will run automatically run updates to bring the database version up to the code version. People running wG outside of docker will see the existing, old update system (7's system got revamped a bit for 8 but is the same idea as 7's where a directory of code changes run... 8 adds directly running .sql and loading .wgpkg files).

I believe this ticket can be closed. The only thing we need to do is create new docker releases that have upgrades in them and convince people to download them =|