Consider running migrations automatically at startup in Docker image

[JonathonReinhart]

A typical behavior of dockerized web applications is to always run any database migrations at container startup (e.g. in an entrypoint script). This way, an upgrade consists of nothing more than changing the image name and recreating the container.

Examples:

• Netbox

This would solve problems encountered by users like #8813 (comment)

[JonathonReinhart]

Well it looks like this was already addressed in #6680.

However, the Docker startup script (for v5.0.11 at least) is severely broken:

...

exec supervisord -c /supervisord.conf

php artisan migrate --force
php artisan config:clear
php artisan config:cache

. /etc/apache2/envvars
exec apache2 -DNO_DETACH < /dev/null

Note that nothing after the first exec line will never run.

• The artisan commands related to the upgrade never run, causing this issue report
• The exec apache2 line does not run, but that is a good thing, because since docker: Fix upgrades #6680, that is supposed to be handled by supervisord.

I fixed up this in #6606, but somewhere along the way it was broken. I suspect that there was a bad merge that went undetected.

I think the right fix is simply this:

...

php artisan migrate --force
php artisan config:clear
php artisan config:cache

exec supervisord -c /supervisord.conf

[JonathonReinhart]

Actually, it looks like the first config:clear is unnecessary:

root@ebda78a7db9f:/var/www/html# php artisan config:clear
Configuration cache cleared!
root@ebda78a7db9f:/var/www/html# php artisan config:cache
Configuration cache cleared!
Configuration cached successfully!

[uberbrady]

This seems pretty reasonable on the face of it. I’m a little worried about what might happen if you “test out” a new image and then go back to your old one, but generally, we try to make our db changes pretty cautiously and backwards-compatibly. I’ll keep thinking about it, but initially, I like it.