Re-running Migrations

Sometimes when testing a PR, we'll need to re-run migrations from pull-requests in the staging server. If we re-stage with Semaphore this might not work.

Let's say a PR introduces a change on the database. If we stage it on a staging server with Semaphore, it will run the migration as part of the staging routine. So when a tester picks it up for the next round of manual testing it will be looking at the code changes the PR introduces and and the updated DB.

Now let's say we stage and test this PR, but but it turns out it will need additional work - so it goes back to the hands of the developer. At some point later on, we'll want to re-stage the PR and make sure we re-run the migration again.

However, if we re-stage with our current semaphore routine the database will not be updated. So, upon the second round of testing, we might be looking at the DB in the state of the previous round of testing. This frequently goes unnotticed (bad) but often it breaks the app (great!) - this warns the tester something is not ok.

We can easily fix this by deleting the "first" migration from the DB table, following these steps:

• login with ssh to the staging server

• go to the current version directory with cd apps/openfoodnetwork/current/

• check which migrations were ran with bundle exec rails db:migrate:status; note the relevant migration ID

• login into the psql shell

• delete the migration using the migration ID delete from schema_migrations where version = '<migration_id>';

• re-stage the PR

Because there is no entry in schema_migrations with that migration_id, staging with Semaphore will re-run the migration and get the both the latest committed code and DB schema as the developer intended to, on that PR 🚀