#542 Add no-op migrations Pull request opened by wild-endeavor TL;DR The existing migrations are not correctly specified. This PR basically rewrites the existing migrations in the form that gorm recommends by adding a series of migrations that should 1. Be a noop for existing Admin users (i.e. users who are up to date with the current set of migrations) 2. Perfectly replicate existing Admin database in the case of a new database. We intend to keep the current (Legacy) migrations around for one release, and then remove them, keeping only the Noop ones, which we will rename. Type ☐ Bug Fix ☐ Feature ☐ Plugin ☑︎ Refactor Are all requirements met? ☑︎ Code completed ☑︎ Smoke tested ☐ Unit tests added ☐ Code documentation added ☐ Any pending items have an associated Issue Complete description We never followed the recommended migration pattern in Gorm. To have an easier time with the work necessary to add mysql support, it'd be better to have existing model migrations cleaned up. Testing Procedure Sandbox Testing using the

flytectl demo

sandbox was done • Spin up flytectl demo cluster, confirm the existing migrations were all run, then run new migrations: confirm no alter commands were run. • Create two new databases, run the old migrations on one, and the new migrations on the second: do a pg_dump and confirm they are identical. The combination of these tests implies that the new migrations map one to one and onto the old migrations. The tests were deleted but can be found here: https://gist.github.com/wild-endeavor/cf2336ebf059a087334a8d8e7efe35b1 The pg_dumps are legacy.txt and noop.txt Tracking Issue This is the first step in fulfilling flyteorg/flyte#3277 flyteorg/flyteadmin GitHub Actions: Build & Push Flyteadmin Image GitHub Actions: Build & Push Flytescheduler Image GitHub Actions: Goreleaser GitHub Actions: Bump Version Codecov: 58.54% (-1.64%) compared to dea5b2a Codecov: 0.00% of diff hit (target 60.18%) ✅ 8 other checks have passed 8/14 successful checks