This job runs on the test stage of a merge request pipeline. It checks:
- A schema dump comparison between the author’s working branch and the target branch, after executing a rollback of your new migrations. This check validates that the schema properly resets to what it was before executing this new migration.
- A schema dump comparison between the author’s working branch and the
db/structure.sqlfile that the author committed. This check validates that it contains all the expected changes in the migration.
- A Git diff between the
db/schema_migrationsthat the author committed and the one that the script generated after running migrations. This check validates that everything was properly committed.
This job is allowed to fail, because it can throw some false positives.
For example, when we drop a column and then roll back, this column is always re-added at the end of the list of columns. If the column was previously in the middle of the list, the rollback can’t return the schema back exactly to its previous state. The job fails, but it’s an acceptable situation.
For a real-life example, refer to
this failed job.
Here, the author dropped the
This failure often happens if your working branch is behind the target branch. A real scenario:
- You check out the
devworking branch from the
maintarget branch. At this point, each branch has their
HEADat commit A.
- Someone works on the
mainbranch and drops the
fk_rails_dbebdaa8feconstraint, thus creating commit B on
- You add column
db:check-migrationsjob fails for your
devbranch’s CI/CD pipeline, because the
structure.sqlfile did not rollback to its expected state.
This happened because branch
dev contained commits A and C, not B. Its database schema
did not know about the removal of the
fk_rails_dbebdaa8fe constraint. When comparing the two
dev branch contained this constraint while the
main branch didn’t.
This example really happened. Read the job failure logs.
To fix these kind of issues, rebase the working branch onto the target branch to get the latest changes.