1. 02 Dec, 2019 1 commit
  2. 23 Aug, 2019 1 commit
  3. 25 Jun, 2019 1 commit
    • Stan Hu's avatar
      Prevent EE backport migrations from running if CE is not migrated · 5f9123687348
      Stan Hu authored
      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>
  4. 17 Jun, 2019 1 commit
    • Yorick Peterse's avatar
      Backport the EE schema and migrations to CE · 6c7a2f164755
      Yorick Peterse authored
      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.