Stuck on 14.10.5 on debian 12

I should note I have a from source install.

So the other day I upgraded my debian 11 server to debian 12. At the same time my gitlab installation was still quite old, 14.9.5, which I had forgotten. After the debian upgrade I noticed gitaly was crashing, which is when I remembered my gitlab install was old and figured I should probably upgrade.

Now I am stuck with the following problem:

• The upgrade path tells me to go 14.9.5 → 14.10.5 → 15.0.5 → 15.4.6 → 15.11.13 → 16.1.5 → 16.3.5 → 16.4.1
• I am unable to install ruby 2.7 on debian 12 as it complains about a too new openssl version during a ruby from source install. Ruby 2.7 is not available in the debian 12 repos (for probably the same reason lol)
• Every gitlab version below 15.10 looks like requires ruby 2.7 and is not supported on ruby 3

I somehow managed to get it to upgrade to 14.10.5 using debian repo’s ruby (3.something), but making a backup from that version does not work as the backup task also crashes (I think cuz it requires gitaly, which is not running, since it crashes, presumably due to wrong ruby version? idk), so my latest backup is of version 14.9.5.

In any case, I now have a bit of a problem if I want to keep to the specified upgrade path. I nuked all ruby related things from my system and tried to install ruby 2.7.8 at which point I found out that didnt work and realized I was in a bit of a peculiar situation lol. Using ruby 3 the sudo -u git -H bundle install step fails.

What happens if I deviate from the upgrade path and go straight to a version that does support ruby 3? This gitlab install is used by like 2 people (me and my housemate) and has not a lot of data on it. I dont care if I need to do something scuffed to make it work again, as in it current state its already fucked anyway lmao. I know the documentation mentions it is important to let the application finish background migrations before going to the next step in the upgrade path, but I dont know how bad it is if I just dont do that?

My last resort backup solution would be restoring my latest working backup on a VM with an older debian version, do the upgrade path there, taking a backup there, and then restoring the backup on the original machine, but I would reaaaallly like to avoid having to do that if possible…

Any help would be much appreciated

Hey
Yeah, what a headache. How much data is in your gitlab? is it just repos?
I’d find a way to migrate all the data from old GitLab into newly / freshly installed latest GitLab, rather than solving all these dependencies issue. Chances are there will be more dependencies issues in the future

honestly its not that much data, but still a sizable amount of stuff from my past that I do not want to lose including non git data like issues / merge requests etc.

So while the idea of just installing a fresh new install and just pushing existing git repos to them has occurred to me, I would loose a sizable amount of data. Also there are a bunch of kinda old projects that only exist in my gitlab install als they’re old school projects etc that I do not currently have checked out anywhere, but I absolutely wanna keep.

Looks like what I’m gonna have to do is the fallback solution I wrote in my original post: restore backup on a temporary VM, go through the upgrade process there, and take backup and restore on my main server again.