I’ve inherited a multi-year old gitlab server that runs all of our code repository. It’s currently running 9.3.8 on an Ubuntu 14.04 OS.
Is there any upgrade path that I can take?
If not, is there a way to export all the projects with all the history and import into a newly created up-to-date server?
Thanks for any help.
One big question that I was curious about is if there is any underlying OS requirements if I try and follow the upgrade path (Upgrading GitLab | GitLab).
Is there a matching OS->GitLab version mapping requirements?
More information, I see this when looking at installed packages:
gitlab-ce/trusty,now 9.3.8-ce.0 amd64 [installed,upgradable to: 11.10.8-ce.0]
Does that mean I can just use the built in apt-get install --only-upgrade gitlab-ce? to take me all the way to 11.10.8? or should I still manually do the standard dpkg -i gitlab-ce?
Again, thank you for any assistance.
You will have quite a lot of work with this. Here is the upgrade path which you have probably seen: Upgrading GitLab | GitLab
Here are all the versions available for Ubuntu Trusty: gitlab/gitlab-ce - Results for 'gitlab-ce' and trusty in gitlab/gitlab-ce (Page 6) which only goes as high as 11.10.8
But you have to go to the intermediate versions between this and your existing version. So your upgrade path looks like:
9.5.10 → 10.0.7 → 10.8.7 → 11.0.6 → 11.10.8
After this, you will need to upgrade from Trusty to the next Ubuntu release so 16.04 Xenial by editing your /etc/apt/sources.list by replacing trusty with xenial. At which point you can continue the upgrade process. Once you have upgraded to Xenial, you can then edit the /etc/apt/sources.list.d/gitlab_ce-gitlab-ce.list file and change from trusty to xenial DO NOT EDIT THIS UNTIL TRUSTY HAS BEEN UPDATED TO XENIAL FIRST ELSE YOU WILL BREAK YOUR GITLAB INSTALL
You can now upgrade Gitlab using the xenial packages.
11.11.8 → 12.0.2 → 12.1.7 → 12.10.14 → 13.0.14 → 13.1.11 → 13.8.8 → 13.12.15
before you can go to Gitlab 14, you have to do your next upgrade to Ubuntu 18.04 Bionic, so again edit the sources.list file from xenial to bionic, upgrade, reboot and then continue the upgrade path.
14.0.12 → 14.3.6 → 14.9.5 → 14.10.5 → 15.0.5 → 15.1.6 → 15.4.6 → 15.10.0
You can at this point stay on Ubuntu 18.04, or you could upgrade to Ubuntu 20.04 focal. Focal also has 15.10.0 package.
Commands for upgrading you need to follow the docs so: Upgrade GitLab by using the GitLab package | GitLab
apt-cache madison gitlab-ce
that command shows what versions can be installed, and then you make the next command based on the output so:
apt install gitlab-ce=<version>
replacing with the version number as shown in the output from the madison command.
As for upgrading Ubuntu, I suggest not to use do-release-upgrade because it has a tendency to remove packages that aren’t in their repositories, so could end up removing your gitlab install. Better is after editing the source files to do:
apt-get clean all
apt-get update
apt-get upgrade
apt-get dist-upgrade
apt-get autoremove
then after these commands reboot into your new version so after doing this on Trusty, on reboot you will be in Xenial. Then you can continue the gitlab commands, so madison to get the version number, and the second command to upgrade to the next version on the upgrade path. Please ensure that before you go from trusty to xenial, that you are on the latest Gitlab available for trusty, else upgrading to xenial might end up upgrading Gitlab to the latest available without following the upgrade path and this will break your install.
It is very important not to edit the gitlab-ce.list file from trusty to xenial, or xenial to bionic until Ubuntu itself has been upgraded, otherwise Gitlab will attempt to upgrade to the latest version available and break your Gitlab. So in summary:
Then repeat those steps for the next Ubuntu release, so bionic and then later focal if you wish. Another alternative, would be on Ubuntu 18.04 and 15.10.0 release to make a backup, and then copy this along with /etc/gitlab/gitlab.rb and /etc/gitlab/gitlab-secrets.json to a new server with Ubuntu 20.04 focal installed, and then restore it as per the Gitlab backup/restore docs. Then it will be a much cleaner Ubuntu, rather than one upgraded from 14.04 to the latest. That said, it is possible to find the older packages and remove them to clean up your upgrade process.
Ensure also after each Gitlab upgrade that background migrations have finished before continuing the next upgrade on the upgrade path - otherwise you can break your Gitlab install see here: Check for background migrations before upgrading | GitLab
Also, before starting your upgrade, make sure you have a full backup of your server just in case something goes wrong. That way you can always revert.
Thank you iwalker, I really appreciate the effort you put into this reply.
One question on this, on each of the OS upgrade steps you started with a different version than what was left on the previous OS level. Is the first upgrade after upgrading the OS to the listed version?
Example, From 14.04 to 16.04, should the first upgrade be from 11.10.8 → 11.11.8?
I will work through this as you describe and report back.
I assume @iwalker found (or made) an upgrade path from 9.3.8 and just split it without thinking that he needed to repeat the version at the end of each split, but (assuming he’s right in stating which versions are available for each ubuntu release) you should just do exactly those upgrade (as you guessed).
The only thing I’ll add, is that in addition to going to focal after getting GitLab tom15.10.0, you should consider also taking the next step, i.e. to jammy (Ubuntu 22.04), while you’re at it. That will bring you to an even newer Ubuntu release that you can then (if you want to of course) stay on for several years. While staying on bionic (18.04) is an option at the moment, (ordinary) security support for that will run out in a few months so it’s probably a bad idea.
Path as per upgrade docs. When upgrading to the next Ubuntu release, shouldn’t be required to repeat the version, eg 11.10.8 since the next upgrade on the path will take you from the trusty to the xenial release anyway. Of course, assuming that is what you meant, as it wasn’t clear.
When I’ve upgraded on Debian, so similar to Ubuntu, never needed to repeat install the same version. That would have required a force anyway since by default it would say 11.10.8 is already installed since the only real thing that changed was the distro release. It’s almost similar in a way, eg: running Gitlab on Debian 11 Bullseye when the official packages weren’t released, it was OK to use the Debian 10 Buster ones. At least until of course it relies on certain version dependencies that may or may not be available between certain distro releases - but that’s a separate topic entirely.
There are certain dependencies for perl around the 14.x versions but at this point we’re still on the same distro (Bionic in this example), so wouldn’t be an issue.
The upgrade paths are split, to show what version you can get to on Trusty before having to go to Xenial and continue the upgrade. Xenial also has the same issue, that it finishes at a certain version, which then requires the next distro upgrade to Bionic to be able to continue.
Thank you grove, and yes, I am planning on going all the way to 22.04 since I’m already in that upgrade process.