Gitlab upgrade - Upgrading git


I am upgrading Gitlab from 13.0 to 13.1.

There is a requirement that I upgrade git from 1.8.3 to 2.2.2[46] per 13.1.0 at Upgrading GitLab | GitLab

I have hunted around and can’t find a CentOS 7 RPM for this purpose. For other packages I’d add a repo, get a list via yum --showduplicates list git and pick the one I want.

I read which details how I can compile my own package but that doesn’t lend itself well to yum-based package management.

Is there a regularly updated and dependable yum repo out there with git packages or is compilation the standard approach for git upgrades please?


1 Like

I since read Is separate upgrade of components necessary when upgrading Gitlab?

Rather than using the zero downtime process, I’ll revert my pre-backup snapshot and try the with downtime process instead …

According to the above post, git should be upgraded by with downtime process

It would be useful to mention this factor in the Gitlab Inc. zero downtime doc if this is correct

Unfortunately, the with downtime upgrade from 13.0.14 to 13.1.11 does not upgrade Git despite that upgrade being a pre-requisite of running v13.1.0.

Based on how Upgrading GitLab | GitLab reads, it does seem like this is intended to be a manual step, so my original inquiry persists and I would like to know if there is a regularly updated and dependable yum repo out there [for CentOS 7] with git packages or is compilation the standard approach for git upgrades please?

Hi @unique
if you are using the official Omnibus package you do not have to update Git on your server. Omnibus package already contains all dependencies it needs. The notes are mostly for people installing from source. This is also specified in the note on that Update page: Specific information that follow related to Ruby and Git versions do not apply to Omnibus installations and Helm Chart deployments. They come with appropriate Ruby and Git versions and are not using system binaries for Ruby and Git. There is no need to install Ruby or Git when utilizing these two approaches.

In case of Omnibus it is just yum or rpm -U command to install the new version. I suggest to go with downtime upgrade as Omnibus package kind of expects it.

this is your docs for Omnibus deployments - Update GitLab installed with the Omnibus GitLab package | GitLab

1 Like

Hello Balonik,

Yes, I’m using Omnibus


[root@myhost ~]# rpm -qi gitlab-ce
Name : gitlab-ce
Version : 13.1.11
Release : ce.0.el7
Architecture: x86_64

Packager : GitLab, Inc.
Vendor : Omnibus

I see the note you refer to in the documentation. I did read it at one point (and promptly forgot) but more recently, I was referred directly to the Upgrading GitLab | GitLab marker in the doc thus bypassing the important info you provided. Yes, the more upgrades I do, the more I think the with downtime upgrades are superior.

Thank you very much for this info which is big help today.

@balonik is 100% correct, upgradin the GitLab Omnibus package automatically upgrades the Git package (and other bundled dependencies) to the new version. You can confirm this with

/opt/gitlab/embedded/bin/git -v

If one or two minutes of downtime is acceptable, I suggest upgrading with downtime. It is quicker, easier, and more efficient. I only suggest zero-downtime upgrades for admins where one minute of downtime is unacceptable.

1 Like

Note that what GitLab calls zero-downtime upgrades actually don’t provide zero downtime. They just do some migrations in the background to lessen the amount of downtime, but the procedure involves restarting puma, and that causes downtime in itself. (I guess that is the reason why I almost always have GitLab’s webinterface return 502 for a short period after I have upgraded - I also guess you can make a HA setup where those restarts are done in a way that means the webinterface stay available, but that is not the case for a standard one server install).


Useful discussion not only for me but I think others see this useful discussion for them as well, thank you all!