Gitlab upgrade Version selection

Major version upgrades contain backward-incompatible changes, including database upgrades, modifications, and migrations. As such, we always recommend taking backups prior to upgrading, and following the suggested upgrade path to avoid issues.

The way to “downgrade” a GitLab Omnibus server’s version to install a previous version using the package manager. Downgrading will reconfigure your instance, and a major version downgrade will try to run background migrations that may be backward-incompatible.

gitlab-ctl revert-pg-upgrade runs this script, to downgrade PostgreSQL server to the previous version. However, any migrations or changes made to the PostgreSQL database itself will persist and may cause problems. For this reason, I don’t suggest using it on a production system.

I suggest reverting to backup of a known good state, and then following this upgrade path:

10.x.x > 10.8.6 > 11.11.8 > 12.0.9 > 12.x.x

If you have problems during the upgrade process, the following commands are very helpful in troubleshooting and understanding the problem:

• gitlab-ctl tail
• gitlab-rake gitlab:check
• gitlab-rake db:migrate:status

Hi @gitlab-greg , Thank you so much. This info help me a lot. Could you please help me to disable the Kubernetes and Auto_devops option by default. In our environment, we wont use Kubernetes but its seems that enabled by default.

Please continue in this topic: Disable Kubernetes and Autodevops option

Hi All,

After upgrading the database from 9.6 to 10.9. Couple of forked repositories are missing. Could anyone help us to know the reason.

Hi @palakkadansar,

I suggest using the following commands to run integrity and db migration checks:

• gitlab-rake gitlab:check
• gitlab-rake db:migrate:status

I also suggest reviewing the db migration error log in
/var/log/gitlab/gitlab-rails/gitlab-rails-db-migrate<date>-<time>.log
and reconfigure log in
/var/log/gitlab/reconfigure/<unix_timestamp>.log
for any errors captured during the upgrade process.