3 ms·
I had to upgrade a slightly older, internal-only GitLab instance for a company a while ago. I was shocked by how many upgrade path dependency problems there we
by PragmaticPulp 5y ago
I had to upgrade a slightly older, internal-only GitLab instance for a company a while ago. I was shocked by how many upgrade path dependency problems there were. Ended up having to roll back to a backup and do the upgrade in a stepwise fashion through various intermediate steps according to their long document on the process, including a fair number of manual commands and migrations and a lot of Googling for obscure error messages.
I enjoy GitLab and it’s the real only option for open self-hosting, but it made me miss the days of having GitHub Enterprise.
- donmcronald 5y agoYeah. I just booted up an old VM to update it. It was on v13 and told me I needed to upgrade to 14.0 first, then 14.8. I did that. Now it's totally broken with crappy error messages and I'll get to waste a few hours today trying to fix it. I switched to Gitea a long time ago and have no regrets.
- cpitman 5y agoLiterally going through this right now. Performing the upgrade from 13 to 14, following the required upgrade path. In the past, you could go from current version -> latest z release -> X.0 release of the next major -> latest minor release of Z. As long as gitlab completed the db migrations and came up, you were (relatively) ok to continue to the next upgrade. Turns out 14 introduces a brand new upgrade failure case. Starting with 14, upgrades can include async db migrations that must complete before you continue upgrading. But once you start upgrading, it's too late, things are hosed, so now I'm falling back to a backup and starting over.