Switching roles between rails and non-rails can break upgrades due to minimum version check referencing old rails version file

Summary

GitLab Rails recipes running in various high av... (#8692 - closed) prevents the gitlab-rails recipes from running when the node configuration is for a non-rails role.

Under certain circumstances this can lead to an outdated /var/opt/gitlab/gitlab-rails/VERSION being left on disk which causes upgrades to fail with messages like:

It seems you are upgrading from 18.4.0-ee to 18.6.0.
It is required to upgrade to the latest 18.5.x version first before proceeding.
Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/#upgrade-paths

Steps to reproduce

  1. Install GitLab Omnibus v18.4.0 on node. Note creation of /var/opt/gitlab/gitlab-rails/VERSION file with contents 18.4.0-ee.
  2. Modify the GitLab configuration to be a dedicated non-rails instance and reconfigure e.g.
        roles(['redis_sentinel_role', 'consul_role'])
        redis['master_name'] = 'gitlab-redis'
        redis['master_ip'] = '10.30.44.86'
        redis['port'] = 6379
        redis['master_password'] = 'password'
  1. Upgrade to v18.5.0. Note /var/opt/gitlab/gitlab-rails/VERSION file remains with same contents.
  2. Upgrade to v18.6.0. Note that the upgrade fails with the following message, despite the current version being 18.5.0:
It seems you are upgrading from 18.4.0-ee to 18.6.0.
It is required to upgrade to the latest 18.5.x version first before proceeding.
Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/#upgrade-paths
  1. Now remove the /var/opt/gitlab/gitlab-rails/VERSION file and retry the upgrade. It should now succeed.

What is the current bug behavior?

Upgrade fails due to presence of old rails version file.

What is the expected correct behavior?

Upgrade should succeed.

Relevant logs

Relevant logs

Details of package version

Provide the package version installation details
Edited by Justin Farmiloe