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.
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.
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:
Install package for gitlab-xx version.
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:
Ensure all GitLab web nodes are on GitLab 13.1.X.
Optionally, enable the global_csrf_token feature flag to enable new method of CSRF token generation:
Feature.enable(:global_csrf_token)
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
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
If some downtime (~1 minute) is acceptable, the upgrade paths here (skipping some minor versions) should work without any problems: Upgrading GitLab | GitLab
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.
The upgrade path I followed in the end was in-line with Gitlab Inc’s doc as follow
11.10.4 > 11.11.8 >>>> 12.0.12 > 12.1.17 > 12.10.14 >>>> 13.0.14 > 13.1.11 > 13.9.3
While 13.1.11 was superfluous for our lone host implementation, I missed that part of Greg’s advice
I’m starting the same on Production next week
