migrations init source
restamp.sh gives a branch's migrations fresh version numbers before it merges.
Why: golang-migrate records one current version in schema_migrations and up applies only versions greater than it. A branch that sat unmerged for three weeks carries a version from before the migrations that have shipped since, so its file is skipped in silence. The migrate job is green, the deploy is green, and the table does not exist. The failure surfaces later as a runtime error.
Full rules: conventional/ci-cd.md.
Usage
BASE=origin/main MIGRATIONS_DIR=internal/migrations ./restamp.sh --dry-run
BASE=origin/main MIGRATIONS_DIR=internal/migrations ./restamp.sh| Variable | Default | What it is |
|---|---|---|
BASE | origin/main | The branch this one will merge into |
MIGRATIONS_DIR | internal/migrations | Where the migration files live |
It renames with git mv, keeps each migration's .up.sql and .down.sql on the same new version, preserves the branch's own ordering one second apart, and refuses to run on a dirty working tree or when the clock is behind the newest version on BASE.
After running it
- Reset the local database. It still records the old versions, so an
upagainst it skips the renamed files. - Re-run the tests against the fresh schema.
- Commit on its own:
git commit -m "chore: re-stamp migrations before merge".
Do not
Run it on a migration that has already been applied on staging or production. Those databases keep the old version, so the renamed file runs a second time.