Add job to verify that upgrading from CE to EE is possible
When upgrading an instance from CE to EE, the instance will already have had all CE migrations run, but not any of the EE-only migrations. These will be run when upgrading to get the DB schema in the desired end state, but this order of migrations (all CE migrations in timestamp order, followed by all EE migrations in timestamp order) is not one we currently test automatically.
In both the gitlab-ce and gitlab-ee repos, we verify that recent migrations can be run and rolled back, but these migrations are always run in global timestamp order, with CE and EE migrations mixed in the order they were written. When running an older EE migration after a newer CE migration, errors can show up when the migrations have different ideas about the overall DB schema at the time of being run.
This is a problem especially when a table or some columns are "backported" from EE to CE at some point, in which case the CE instance being upgraded to EE already has the table/column, and the EE migration that originally added the table/column, and any later EE migrations that modified the table in some way (adding, removing, renaming, type-changing columns) would fail. To fix this, the EE migrations need to be modified to be skipped if the table and columns already exist. The CE migration also need to modified in EE to make its down
method a no-op, so that when rolling back in timestamp order, earlier EE migrations that assume the table exists don't find it to already have been removed.
Issues like this could have been caught ahead of time if we had a job on gitlab-ce that took the CE branch, ran all migrations (or rake db:schema:load
), then checked out the corresponding EE branch (ee/<ce-branch>-ee
or just ee/master
) and ran all EE migrations there, on top of the existing CE schema. On gitlab-ee, the same job would first check out the CE branch, run its migrations, check it out its own branch, and run the EE migrations on top of it.
A job like this would have allowed us to catch and fix issues like gitlab-qa#240 (closed) and gitlab-qa#238 (closed) earlier.