Capability to upgrade a GitLab instance to Heptapod
It should be possible to upgrade a GitLab CE instance to Heptapod, and it certainly has been possible for many Heptapod versions in the past.
However, some of our data migrations were breaking rules that once were soft and have since become mandatory. It was reasonable because many of these rules are geared towards high volumetry (as can be found on gitlab.com) which was not a concern to us at the time yet have become enforced upstream.
The typical case would be AddHgAsDefaultVcs
as it was until the merge of GitLab 15.8: it changes the schema (default value on application_settings
) and updates a column on the namespaces
table: it wouldn't have passed upstream review at the time, but there is a strict enforcement nowadays that migrations have to use either Data Definition Language (DDL) or Data Manipulation Language (DML). It makes the migration fail if running anew on recent Heptapod versions (which won't happen unless upgrading from an upstream GitLab instance because it dates way back). Also it breaks all the RSpec test that contain any migration test.
The problem in RSpec tests will of course be solved with the merge of GitLab 15.8, yet in a minimal way that is not suitable to upgrade an upstream GitLab CE instance.
This issue to keep track of the work need for such upgrades to be supported:
-
application_settings.vcs_types
should be introduced by a single migration, with the correct default set in the schema (single row table) -
namespaces.default_vcs_type
does not need a migration of the value if starting afresh on current Heptapod versions. ANULL
value means to default to Application Settings, so we don't need any backfill. -
actual testing of an upgrade from GitLab (how to automate that?)