I’ve managed to end up in a problematic scenario. I started out with the task of updating a GitLab CE installation that’s been stuck on version 13.12.15 due to the host OS being too old (Ubuntu 16.04.7 LTS). The error I was getting as simply that there where no newer versions for the package gitlab-ce.
I started out by upgrading Ubuntu to 18.04.6 LTS and after successfully doing that, attempted to continue the upgrade path for GitLab as per the documentation (I tried to install GitLab CE 14.0.12). This failed with the same error as before, Version '14.0.12-ce.0' for 'gitlab-ce' was not found. I followed the instructions on the GitLab site to make sure the APT sources was in place. Same thing. Somewhat frustrated, I assumed that Ubuntu 18.04 also was too old, so I continued updating to 20.04.5 LTS. Same problem. Finally updated to 22.04.2 LTS. Still same problem… At this point I started to realise something is not right. I finally realised that the instructions on the GitLab site only installs the APT package source for gitlab-ee and not gitlab-ce. So I instead managed to correctly add the right package repository.
Now for the problem… The earliest available package for Ubuntu 22.04.2 LTS (ubuntu/jammy) is GitLab CE 15.5.0, way newer then my next step in my upgrade path, 14.0.12.
How screwed am I? Is it possible to manually install the Ubuntu 20.04 (ubuntu/focal) packages on my 22.04 system (I’m not sure what the differences are)? Is there any chance at all that older GitLab CE packages will appear for Ubuntu 22.04 (I’m guessing not very likely)? Is there a way to generate my own ubuntu/jammy packages for older GitLab versions, or will this mean a bunch of other challenges (it does not sound very straight forward)?
I will attempt to see if we can roll back the OS upgrades by reverting to system backups, but worst case is that our backups are on application level and not on OS level.
The gdebi package allows for resolving dependencies that may be required by the manually downloaded Gitlab package, then just repeat the gdebi command for each gitlab package. I believe prior to 15.4.x you won’t have this issue, but 15.4.6 or whatever version is on the upgrade path right now will have a load of perl dependencies.
Download each of the packages on the upgrade path, and follow the upgrade path through until you get to 15.5.0 using the above step to install the downloaded packages. Then you can continue using the normal repository install commands to upgrade from 15.5.0 to the latest as per the Gitlab docs.
Make sure that the packages you download are amd64 since there are also ARM packages, for Raspberry PI, etc, and you don’t want them unless you are using that kind of CPU.
No earlier packages will appear for Ubuntu 22.04 so this is only really your way forward. People have ran Gitlab Focal packages on Ubuntu 22.04 until versions became available.
Theoretically, you could change the /etc/apt/sources.list/gitlab_ce-gitlab-ce.list file entries from jammy to focal, and use the standard apt install commands as per the Gitlab docs to continue your upgrade. Will save on downloading manually then and at the same time will also download any dependencies required automatically without the use of gdebi.
Thank you so much for the advice, really a life saver!
While a bit scary running packages for another Ubuntu release, it’s reassuring to hear that this is a strategy already used by the community before the 22.04 packages was available.
I use Debian 11 for mine, and before the Bullseye packages were released, my install was running fine with the Debian 10 packages. I just did the same, change the list file to buster instead of bullseye to get the packages. When the official packages were released, I just updated the list file to bullseye. So similar in what you can do with using focal to get yourself upgraded, then edit the list file later to jammy once you’re at the version where jammy packages exist.
As I said, the only issue that might occur is when the dependencies for perl come into play around 15.3.6 or 15.4.x so keep an eye out for that.