Hi, I have a question about upgrading GitLab. We are currently using GitLab Community Edition self-hosted version 15.8.0. We are planning to upgrade to the enterprise edition, which costs $29/month.
I’d like to know the process for upgrading from the community edition self-hosted 15.8.0 to the latest enterprise edition. Is there a way to do this? Please let me know the process.
There is a page in the gitlab documentation for upgrading from CE to EE : Convert Community Edition to Enterprise Edition | GitLab
You should upgrade the edition first (ce to ee 15.8).
And then update from 15.8 to the current release following the upgrade path. There’s a tool for determining the upgrade path : Upgrade Path
But you’ve got quite some work : 15.8.6 => 15.9.8 => 15.10.8 => 15.11.13 => 16.0.9 => 16.1.7 => 16.2.10 => 16.3.8 => 16.4.6 => 16.5.9 => 16.6.9 => 16.7.9 => 16.8.9 => 16.9.10 => 16.10.9 => 16.11.10 => 17.0.8 => 17.1.8 => 17.2.7 => 17.3.3
Also in between each of those upgrades on the upgrade path you will have to wait until database migrations have finished. If you start the next upgrade on the upgrade path before database migrations have finished, you can break your Gitlab installation.
Make sure to have a snapshot or backup of your server before upgrading.
Your upgrade path has 19 steps but the tool has 5
DB migrations are performed by rake. If your approach to migrating the db is to start gitlab and let it handle it, it will do the db migration in the background with sidekick and you wont know when its done
I copied the upgrade path from the tool at the date I replied to your post. It may have had a bug. The new result from the upgrade tool seems more logic.
15.11.13 => 16.3.8 => 16.7.9 => 16.11.10 => 17.3.3
I see there’s a command to check the status of a db migration. Maintenance Rake tasks | GitLab
It might be better to start gitlab and let it handle the migration (maybe there are other things to migrate besides the db) and then exec into the container (if you’re containering) and run that status command.
Totally incorrect statement. Migrations can be checked in the web interface, and from the console. You can go to Admin → Monitoring → Background Migrations and you can clearly see there whether they have finished or not. You can also see it from the console as well using cli commands like you suggested.
Also, you shouldn’t be stopping Gitlab before attempting an upgrade as well, since certain Gitlab services are required to be active - Gitlab stops the services it needs to stop. There is no need for you to start/stop Gitlab it has nothing to do with running the migrations. Migrations can be skipped by creating a file in /etc/gitlab - but then it means you have to manually run them when Gitlab is running after the upgrade has been completed.
Has the Admin → Monitoring → Background Migrations panel always been there?
Note also
Certain releases may require different migrations to be finished before you update to the newer version. Two kinds of migrations exist. They differ, and you should check that both are complete before upgrading GitLab:
Also, you shouldn’t be stopping Gitlab before attempting an upgrade as well, since certain Gitlab services are required to be active - Gitlab stops the services it needs to stop. There is no need for you to start/stop Gitlab it has nothing to do with running the migrations
Good to know.
No, but since it exists in the version that the original poster mentioned, eg: 15.8.0, then whether it existed or not previously in older versions is irrelevant to this thread.
All methods, webui as well as console be it normal database migrations or any other ones are fully documented in the Gitlab documentation. And as I already mentioned in my original reply to this thread, you have to wait until database migrations have finished before attempting the next upgrade - the methods on how to do that is irrelevant at this point.
The two types of migrations, as from the link you quoted:
The webui is for the batched background migrations as well as the console ones (db:migrate:status). The second type that had two different commands for checking no longer exists from 15.1.x. Since this thread is about 15.8.0, then the webui or the db:migrate:status are the only commands you need to check and use and these are the only migration type that you need to check. In fact the commands used for the second type (older versions) was:
gitlab-rails runner -e production 'puts Gitlab::Database::BackgroundMigration::BatchedMigration.queued.count'
gitlab-rails runner -e production 'puts Gitlab::Database::BackgroundMigrationJob.pending[0].pretty_inspect'
are only for 15.0 and earlier. Even in addition to the db:migrate:status command, even back then.
Your comment above makes the insinutation that both types need to be checked even on new releases, which is incorrect. The correct interpretation as is explained in the documentation is, if you have 15.1 and higher, check the batched migrations using the appropriate commands, if you are using 15.0 or older, then you use the second method that doesn’t include the webui.
But all of that is off-topic and irrelevant to this thread.
All I did was quote the current version of the documentation.
Is it enough to follow the current version of the documentation for all migrations, or should I follow the migration instructions provided with each version? For example, should the OP start with following the instructions from registry.gitlab.com/gitlab-org/gitlab-docs:15.11
?
That link didn’t work, but this would be the correct one. I’ve linked to background migrations so that I can use it for explanation: Check for background migrations before upgrading | GitLab
On this page, there are console commands listed very similar to the ones mentioned in my previous post. What you will also see the batched migrations is also shown lower down that show what I mentioned about going to Admin → Monitoring → Background Migrations
As mentioned for 15.1 and higher, that is the only one you need, which is also mentioned in the current 17.x documentation as well.
The 15.11 documentation differs by still listing the older methods, because they applied for 15.0. At that point in time when the 15.11 documentation was written/updated, etc, people were still on far older versions prior to 15.1 and therefore the documentation does differ somewhat. For 15.11 however, there is no need to follow the older documentation since in relation to the migrations, it’s explained to use the method below:
of which I already quoted.
If you are on version 15.1 and higher, then yes. Even for 15.0 and older, there are still the instructions in the current documentation to tell you how to check using the older methods and therefore no need to refer to the older documentation. And if you aren’t 100% sure, then you can always feel free to view the old documentation just to make sure.
It is far worse for older versions like Gitlab 8 or 9 or even older since it’s hard to find readily available documentation for those versions and those versions do need to reference older documentation as the current one doesn’t apply. Some versions you can run locally as a docker container and access, but they are only available up until a point in time. Anything older than Gitlab 7 is practically impossible. But then nobody should still be using such an old version of Gitlab and should have upgraded a long time ago 
Ok, so what if gitlab stops by itself? Can you please chime in on my question here