What problem are you trying to solve with Submitty
A developer creates a complicated PR that includes a database migration file.
The developer follows these instructions:
https://submitty.org/developer/development_instructions/migrations
which creates a migration file with today's date.
The PR is complicated, and the reviews and revisions take time. Weeks perhaps months go by before the PR is merged. When the PR is merged, the migration file still has the original date. Since unapplied migrations are sorted chronologically and then run in that order, this means that the migration may run in a different order for a system administrator updating a system that is a few months or even years out-of-date. Out-of-order migrations might fail if there are sequenced dependencies in the changes.
Describe the way you'd like to solve this problem
Let's add a Gihub Action / regression test that checks the datestamp on any migrations files in the PR. If the datestamp is more than 7 days stale, the test should fail. The developer should manually update the filename so that it is more current.
Describe any potential alternatives you'd tried to solve the problem
Alternatively, we could write an action or hook (?) that automatically renames the migration filename when the PR is squash & merged. This would ensure perfect chronologic order. But it could be problematic. The developer who created the PR and anyone who tested the PR will have 2 migration files on their system with similar names but different timestamps, and this could be confusing or even buggy.
What problem are you trying to solve with Submitty
A developer creates a complicated PR that includes a database migration file.
The developer follows these instructions:
https://submitty.org/developer/development_instructions/migrations
which creates a migration file with today's date.
The PR is complicated, and the reviews and revisions take time. Weeks perhaps months go by before the PR is merged. When the PR is merged, the migration file still has the original date. Since unapplied migrations are sorted chronologically and then run in that order, this means that the migration may run in a different order for a system administrator updating a system that is a few months or even years out-of-date. Out-of-order migrations might fail if there are sequenced dependencies in the changes.
Describe the way you'd like to solve this problem
Let's add a Gihub Action / regression test that checks the datestamp on any migrations files in the PR. If the datestamp is more than 7 days stale, the test should fail. The developer should manually update the filename so that it is more current.
Describe any potential alternatives you'd tried to solve the problem
Alternatively, we could write an action or hook (?) that automatically renames the migration filename when the PR is squash & merged. This would ensure perfect chronologic order. But it could be problematic. The developer who created the PR and anyone who tested the PR will have 2 migration files on their system with similar names but different timestamps, and this could be confusing or even buggy.