Are you 100% sure this is a source installation, and not the Gitlab omnibus package? Can you do:
dpkg -l | grep -i gitlab
just to verify if a package is installed or not, as I would normally expect source installs to be in a different location based on the info you provided so far.
Hi iwalker,
I am positive it is a omnibus CE install, sorry if I made you think otherwise, I have updated the inital post, there was misleading info that I found in Gitlab for self-compiled instances no related to ours, my bad
dpkg -l | grep -i gitlab
ii gitlab-ce 12.6.1-ce.0 amd64 GitLab Community Edition (including NGINX, Postgres, Redis)
ii gitlab-runner 14.2.0 amd64 GitLab Runner
ii node-hosted-git-info 2.8.5-1 all Provides metadata from Github, Bitbucket and Gitlab
I am not sure if I need to proceed with the whole upgrade one by one, or the install will take care of it:
Update Ruby
Update Node.js
Update Go
Update Git
Update PostgreSQL …
I am not sure about PostgreSQL, I thought would be manual upgrade first
What I am sure is that I will need to make intermediate upgrades between major versions:
E.g Version: 12.6.1 → latest 12.. / 13 to latest etc
Ah, your initial post had links to source upgrades, hence why I asked. Also you mention updating ruby, etc, which is simply not needed with an omnibus installation, since Gitlab takes care of updating it’s components as and when it’s needed.
Suggest you start here, this link has a ton of resources to look at including the upgrade path - since you will need to follow the upgrade path to ensure a successful upgrade: GitLab Upgrade Path Resources
You do not need to stop Gitlab, if you do this, services required for the upgrade process will not be running, and things like database migrations will not occur. Gitlab will stop any services it needs to stop during the upgrade process. Postgresql is also bundled in the omnibus package, and Gitlab itself will take care of upgrading this when it’s needed.
You also need to make sure background migrations have finished before starting the next upgrade on the upgrade path. If you don’t, and upgrade before they have finished, you will break your Gitlab installation.
Nope, not really painful. A bit time consuming to go through each upgrade. The package update itself takes no more than 5 mins, but background migrations depending on size and amount of data on your Gitlab install can take hours - I’ve had one install I had to wait 8 hours before I could start the next upgrade.
You are basically just using apt commands to upgrade the gitlab-ce package that is installed. Nothing else needs to be done other than this, since this package contains all the updates things like ruby, postgres, etc as and when required. To get to latest 17.x, you are prob looking at a few days at best. I doubt you’ll work your way through all upgrades on the upgrade path any quicker than that, again depends how many repositories and data you have.
Obviously, make sure to have backups, check the Gitlab backup documentation for that.
Other than the standard apt-get update to refresh your repo data, he could well mean something I came across when I was on Gitlab 12.9.3 that I didn’t see any new packages appearing in the repo data. Also recently similar situation in as much that the SSL certificates would not update on previously configured repositories. In both of these situations, it’s enough to do this from the install docs:
the above command is for gitlab-ce so safe for you to run. Otherwise, change gitlab-ce to gitlab-ee in the URL if using Enterprise Edition. This will refresh your repo data, similar to what I experienced when 12.9.3 was the latest I saw available. After running the command, newer versions then showed up and could then continue the upgrade path.
For the SSL error I mentioned when certificates had expired, that command will also help out.
For security reasons, it’s probably best to download the script first and then read it to see what it does before running it like the command above. It just depends on whether you trust the source it comes from. For Gitlab I run it as it (my personal preference, others may disagree with me and that’s fine), for other sites I may not trust, I would probably download and read it first. If you wish to do that, being more security conscious then just do:
Exactly. Recently I tried to upgrade my Gitlab I think to 16.11.2 version, but I wasn’t allowed to see the new available versions and I had to run the process @iwalker mention above.
I just want to thank everyone for all the advise, trying to get scheduled this job, it is our production bread and butter environment for one of the products, so good luck to us
I have GitLab Community Edition [15.11.0] installed in my system on RHEL 8 and i wanted it to upgrade .Could you Please advise on which version we should upgrade ?appreciate if you can suggest or provide upgrade steps .
reference doc we received for security patch GitLab Critical Patch Release: 17.1.2, 17.0.4, 16.11.6 | GitLab
Found the first hurdle, even with the omnibus CE package I am having issues with 13.6 and 13.7 upgrades and postgresql, the packages expect version 12.5 but looks like 11.5 still installed
DB location default folder: /var/opt/gitlab/postgresql
Followed instructions here: Database settings | GitLab
Launched:
sudo gitlab-ctl reconfigure
sudo gitlab-ctl pg-upgrade
No errors found but the dashboard still showing version 11.7!
The version of the running redis service is different than what is installed.
Please restart redis to start the new version.
sudo gitlab-ctl restart redis
[2024-08-02T15:43:11+02:00] WARN: This release of Cinc Client became end of life (EOL) on May 1st 2023. Please update to a supported release to receive new features, bug fixes, and security updates.
For redis I am launching sudo gitlab-ctl restart redis but the warning stays, the other one I don’t really know what to do with it
