I think this didn’t get much traction because that’s a rather unusual approach to migrations. Depending on the environment/build env, the usual thing to do is:
Local development (:dev):
manually run
mix ecto.migrate
Local testing/CI (:test):
run migrations as part of the tests - the test task is aliased to
test: ["ecto.create --quiet", "ecto.migrate", "test"]
in mix.exs
Production (:prod):
- Package the app as a release,
- Add a release task,
- Run the migrations at startup.
If you’re using Docker, this could be:
CMD ["sh", "-c", "bin/app eval MyApp.Release.migrate && bin/app start"]
Usually there are healthchecks in place, so if the migrations fail, the deployment process should pick up on that and abort the deployment.
The case in the original post was about running the new version regardless if the migrations succeed or not, but I think this can be easily achieved with running the migrations as a separate command and just ignoring any errors.
