Description
Hi,
four years later after 3055 and I think this feature is still relevant! Inspired by How to Fix or Avoid ‘Ignored’ Migrations in Flyway, I agree skipExecutingMigrations is a good practice to deal with incompatible migrations from higher stages that are merged into lower stages. Like an index was created in production for a table that was already dropped by a newer migration in the development stage.
However, if flyway is triggered by Spring Boot or CD/CI, the skipExecutingMigrations property is unsafe because if another migration for a feature is merged at the same time with the migration which should being skipped, both migrations will be skipped. So the only option is to run flyway manually with the skipped migration against that stage and merged into the development branch stage at the same time. If the time between the manually triggered migration and the merge into the development branch is too long or a deployment process is already running and another automated migration is triggered, this migration will fail with a validation error as the migration is in the history but not in the codebase! Another point is that any manually invoked migration process can have configuration errors. We therefore advise against such practices!
The only safe way to deal with this situation is to generally enable skipExecutingMigrations for preproduction and include this migration version in a skip list. This can be done together with merging the incompatible script.
Bypassing such behavior is possible with the API, but leads to multiple validation and migration executions. I drafted such behavior with a combination of flyway#validateWithResult(), target and skipExecutingMigrations, but the result is clunky and slows down the migration process immensely.
Adding a property like skipExecutingMigrationVersions would be so perfect. In DbMigrate, the condition just needs to be changed:
If skipExecutingMigrations=true and skipExecutingMigrationVersions is empty or contains the current migration version, the current migration should be skipped. This change is compatible and provides an optional way to restrict the skipped migration versions.
I would contribute a consistent implementation including tests and documentation if you like this idea. Also I would extend the spring-boot-starter implementation.
Greetings,
Ben