Query regarding upgrade path doc https://docs.gitlab.com/ce/update/

Replace this template with your information

In the Upgrade Path section of Upgrading GitLab | GitLab

The upgrade path is 8.11.x → 8.12.0 → 8.17.7 → 9.5.10 → 10.8.7 → 11.11.8 → 12.0.12 → 12.1.17 → 12.10.14 → 13.0.14 → 13.1.11 - > 13.x (latest)

This seems to be inconsistent with the top two rows in the table immediate below the above line as follows

Neither of the top two table rows i.e., 13.0.14 → 13.4.3 and 13.0.14 → 13.2.10 include the → 13.1.11 - > intermediate step whereas the line that begins “The upgrade path is” includes 13.1.11.

I’d like to know if it is essential to upgrade via 13.1.11 or not please?

I am running mainly 11.10.4 and planning a series of upgrades to the latest available (then automated upgrades thereafter).

Hi, if in doubt I suggest doing it. Not so long ago, I upgraded from 12.9.3 and did every single release between 12.9.3 until the latest version which was about 80 upgrades and took me two days.

Worst thing you can do is miss a release and then have to restore from a backup. I’m unable to say whether the documentation is correct or not as I don’t work for Gitlab, but better safe than sorry.

And just make sure after each upgrade you check the background migrations and make sure they are “0” before continuing.

Hi Ian,

Thanks for getting back to me. I will include the intermediate version in my update path as you suggest.

Unlike your approach, at this stage I don’t plan to do each and every migration from v11 to v13.
That would be very labour intensive and prolonged and Gitlab Inc. don’t recommend that rather they have the upgrade path that I referenced in the docs, so I’ll stick to their doc.

I appreciate your help and insights.

Cheers!

Yep, I wasn’t sure of the upgrade path, so I just played it safe. And yes it takes ages that way. But at least guaranteed I didn’t miss anything.

So yes, providing you just follow the path in the docs, that will be fine. So something like:

1. Install package for gitlab-xx version.
2. When finished and gitlab has started after upgrade, run this:

gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'

when it reports zero, do the next upgrade and then repeat the background migration command above. And so on until finally you are running the latest version.

@unique Sorry for any confusion. The 13.1 step of the upgrade path is only required if you have multiple GitLab application nodes (GitLab Rails servers) running behind a load balancer.

So, if you are using multiple Rails servers and specifically upgrading from 13.0, all servers must first be upgraded to 13.1.X before upgrading to 13.2.0 or later:

1. Ensure all GitLab web nodes are on GitLab 13.1.X.

2. Optionally, enable the global_csrf_token feature flag to enable new method of CSRF token generation:

   Feature.enable(:global_csrf_token)
   

3. Only then, continue to upgrade to later versions of GitLab.

@iwalker For future reference, upgrading every single minor release is only required for Upgrading without downtime. (See also, Zero-downtime updates). If you don’t need zero downtime between updates, there’s no need to upgrade each patch version one at a time.

If a minute of downtime between version upgrades is acceptable, the Upgrade paths listed here should “just work” without any problems: Upgrading GitLab | GitLab

@gitlab-greg good to know thanks. Although I generally upgrade as soon as a new one appears so I’m never usually that far behind. From 12.9.3 was an exception since it stopped for some bizarre reason refreshing the apt repo. By the time I realised it was after six months so had a bit of catchup to do

Hi Greg,

Thanks for getting back to me.

I have several individual, unrelated servers, each with a single runner, so I will not apply the specific 13.1.x patch on my upgrade path to the latest version based on your recommendation.

In your latter note on this thread, you said " upgrading every single patch release is only required for Upgrading without downtime ."

I read that doc before and based on the following statements in that doc :

“You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to 9.3.”

and

“it’s possible to upgrade to a newer major, minor, or patch version of GitLab without having to take your GitLab instance offline.”

I think you mean a patch release is a single patch, minor or major version change i.e., 11.10.1 to 11.10.2 OR 11.10 to 11.11 OR 11.11 to 12.0 are potential zero downtime upgrades?

I hope so because I’ve just done the latter two of those upgrades online and with the exception of one issue, which I will post that another thread, they seemed to complete ok

Cheers!

@unique Thank you for bringing this up! That was a typo, and your understanding is correct.

For zero downtime upgrades, patch versions are not relevant. What is relevant is the minor version.

For zero-downtime upgrades, increment one minor version at a time.

• You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not [9.1] to 9.3.

If some downtime (~1 minute) is acceptable, the upgrade paths here (skipping some minor versions) should work without any problems: Upgrading GitLab | GitLab

Hi Greg, Thanks again; I’m grateful for your help.

Hi There,

I was on version ten .

This is the sequence I ran

OK, I figured it out.

I ran the following in sequence and checked each time. This keeps the upgrade paths in tact.

sudo apt update
curl “https://packages.gitlab.com/gpg.key ” -o /tmp/omnibus_gitlab_gpg.key
sudo apt-key add /tmp/omnibus_gitlab_gpg.key
sudo apt update
sudo dpkg --configure -a
sudo apt-get install gitlab-ce=11.11.8-ce.0
sudo apt-get install gitlab-ce=12.0.12-ce.0
sudo apt-get install gitlab-ce=12.1.17-ce.0
sudo apt-get install gitlab-ce=12.10.14-ce.0
sudo apt-get install gitlab-ce=13.0.14-ce.0
sudo apt-get install gitlab-ce=13.1.11-ce.0
sudo apt-get install gitlab-ce=13.8.4-ce.0

sudo apt-get install gitlab-ce
sudo apt update
sudo apt upgrade
sudo apt autoremove

PS: I would assume that anyone update/upgrading there gitlab on ubuntu server you can follow the same and obviously just start your version script from the version you on.