Quoting flyway doc at https://flywaydb.org/documentation/migration/repeatable :
Repeatable migrations do not have a version. Instead they are (re-)applied every time their checksum changes.
This is very useful for managing database objects whose definition can then simply be maintained in a single file in version control.
Within a single migration run, repeatable migrations are always applied last, after all pending versioned migrations have been executed. Repeatable migrations are applied in the order of their description.
This sounds exciting however I can't seem to find any clarification on how this actually works and on how to initialize repeatable migrations. I understand that for Versioned migration I can create a base migration (https://flywaydb.org/documentation/existing) and then run the baseline command to get things ready for my future versions. However for repeatable migrations I do not understand how flyway is able to checksum changes.
Instead they are
(re-)applied every time their checksum changes.
Is flyway making the assumption I am recreating my database from scratch to get the checksum comparison working? This would explain how it is able to compare checksum (since it has access to the file-definition of object already in database).
UPDATE: I know it s been some time, the solution I was looking for is flyway repair. It will sync a pre-existing schema with flyway internal checksum table. https://flywaydb.org/documentation/commandline/repair
I've tested flyway and now understand initialization: flyway will ignore existing scripts / migrations as long as the file name will not have a specific prefix (I think 'REPEATABLE' is the default) - so as long as migrations are not renamed to be executed flyway will ignore them.