flyway validate: Verify Checksums in CI
flyway validate confirms that the migrations recorded as applied still match the files on disk, failing if any checksum differs.
validate catches the classic mistake of editing a migration that already ran. Running it in CI turns a silent drift into a loud, early failure.
What it does
flyway validate compares the checksum, version, and description of each applied migration in the schema history against the current file. Any mismatch, missing migration, or extra applied migration causes a non-zero exit.
Common usage
flyway -url=jdbc:postgresql://db:5432/app \
-user=ci -password="$DB_PASSWORD" validate
# migrate only if validation passes (default behavior of migrate)
flyway -configFiles=flyway.conf validateOptions
| Flag | What it does |
|---|---|
| -ignoreMigrationPatterns | Ignore specified states, e.g. "*:missing" |
| -validateMigrationNaming=true | Also validate filenames follow the naming rules |
| -cleanDisabled | Unrelated safety flag often set alongside in CI |
| -url / -user / -password | Connection details |
In CI
flyway migrate runs validate automatically first, so a separate validate step mainly helps in a read-only check before deploy. If a legitimate change forces a checksum update, run flyway repair to realign the history rather than disabling validation.
Common errors in CI
"Validate failed: Migration checksum mismatch for migration version X" is the headline error: an already-applied file was modified. "Detected applied migration not resolved locally" means a file present in history is missing on disk. Fix by restoring the file, or run flyway repair to update the stored checksum after an intentional change.