Migrations

Why?

There are some database changes that GORM auto migration will not handle for us. These need to be dealt with separately.

How?

To do this we are using a migration module called gormigrate. Migrations are run at startup right after the automigration is run.

Adding a new migration

• Each migration should have a separate file in /internal/migrations prefixed with a timestamp which will also be the migration ID
• Each migration should have a single function named to describe the change which returns a *gormigrate.Migration
  • Both migrate (up) and rollback (down) should be implemented if possible
• Every migration should have a corresponding test (especially for migrations which are changing data)
• A new migration scaffold can be created using MIGRATION_NAME=someMigrationNameHere make generate-migration
  • This will give the migration files a proper timestamp as well as (empty) tests

To be run, every migration function should be added to the list in postMigrations

Pre-migrations

We currently have a single migration in preMigrations, i.e. running before AutoMigrate step that is responsible for synchronizing the database schema.

The use of preMigrations is (currently) discouraged, as it may cause unexpected failures due to the existing usage of application code (common.GetClustersFromDBWhere) in some of the already-released migrations.