If a user upgraded to any GitLab 11.x EE version but switched back to CE, it's possible the state of the EE tables are not in the right state for the EE backport migration to work properly. In particular, there were three tables that had trouble: * epics * geo_event_log * vulnerability_feedback The EE backport migration would fail while trying to add foreign key constraints because a key didn't exist in the table. This happens because any EE migration that add or removed columns between v11.0.0 and v11.11.3 are not guaranteed to be applied in an CE installation. The EE backport schema does not individually backport these migrations. We now check if certain columns are present to determine whether the backport migration is in the proper state. CE users are required to upgrade to v11.11.3 EE if they ever installed EE previously before they can go back to v12.x CE. Tested via: ``` git checkout -f v11.0.0-ee bundle exec rake db:reset git checkout .; git checkout -f v11.11.3 bundle exec rake db:migrate git checkout .; git checkout -f v12.0.0 bundle exec rake db:migrate <failure happens> ```
Automatically update MR merge-ref along merge status See merge request gitlab-org/gitlab-ce!29569
Migrate managed clusters that aren't using managed features to unmanaged Closes #62772 See merge request gitlab-org/gitlab-ce!29251
There are clusters that have Kubernetes namespaces stored which are missing a service account token. These namespaces are unable to be used for deployments, so marking the clusters as unmanaged will allow the platform credentials to be used instead.
This couples the code that transitions the `MergeRequest#merge_status` and refs/merge-requests/:iid/merge ref update. In general, instead of directly telling `MergeToRefService` to update the merge ref, we should rely on `MergeabilityCheckService` to keep both the merge status and merge ref synced. Now, if the merge_status is `can_be_merged` it means the merge-ref is also updated to the latest. We've also updated the logic to be more systematic and less user-based.
Add migrations needed to encrypt feature flags client tokens See merge request gitlab-org/gitlab-ce!29320
Migrate Kubernetes service integration templates to clusters See merge request gitlab-org/gitlab-ce!28534
Make plaintext token column not null, add new token_encrypted column and index on project_id & token_encrypted. Post deployment migration to encrypt existing tokens.
This backports all EE schema changes to CE, including EE migrations, ensuring both use the same schema. == Updated tests A spec related to ghost and support bot users had to be modified to make it pass. The spec in question assumes that the "support_bot" column exists when defining the spec. In the single codebase setup this is not the case, as the column is backported in a later migration. Any attempt to use a different schema version or use of "around" blocks to conditionally disable specs won't help, as reverting the backport migration would also drop the "support_bot" column. Removing the "support_bot" tests entirely appears to be the only solution. We also need to update some foreign key tests now that we have backported the EE columns. Fortunately, these changes are very minor. == Backporting migrations This commit moves EE specific migrations (except those for the Geo tracking database) and related files to CE, and also removes any traces of the ee/db directory. Some migrations had to be modified or removed, as they no longer work with the schema being backported. These migrations were all quite old, so we opted for removing them where modifying them would take too much time and effort. Some old migrations were modified in EE, while also existing in CE. In these cases we took the EE code, and in one case removed them entirely. It's not worth spending time trying to merge these changes somehow as we plan to remove old migrations around the release of 12.0, see https://gitlab.com/gitlab-org/gitlab-ce/issues/59177 for more details.
These clusters were created before we introduced the option to manage your own cluster, and not having a Kubernetes namespace present means that we have tried and failed to create one - and therefore we cannot manage your cluster for you. The 5 minute window should prevent a race condition where a cluster has only just been created and we haven't had a chance to create any resources for it yet.