We use the Omnibus tool to maintain and upgrade our Gitlab Setup.
On upgrading from v16.1.5 to v16.3.6 in one setup, the Background Migrations went through automatically and showed up in the Admin Panel UI.
Whereas in another setup running the exact same command for upgrade didn’t run the Background Migrations when upgraded to v16.3.6 and the Migrations had to be manually triggered using gitlab-rake db:migrate
Does anyone know why this happens and is it a good practice to run gitlab-rake db:migrate:status before and after every upgrade?
For me, migrations have always ran. I do now that some things can also be skipped by creating certain files in /etc/gitlab but I think that’s mostly to do with skipping reconfigure, I don’t remember anything for stopping migrations that way. But you can check for the existence of files in /etc/gitlab that may be causing this issue.
I’ve also never had that option enabled in my Gitlab config, even by default it’s always enabled for migrations to run. Migrations usually get queued and show in the web interface, so it’s weird that yours haven’t been running on one of your servers if files or config options haven’t been set.
I’d always recommend running gitlab-rake db:migrate:status simply because it can be finicky. I’ve noticed it way more on versions <13 but as you can see- sometimes even on the newer versions it might not run for whatever reason.