Equivalent to distillery's boot hooks in mix release? (Elixir 1.9)

Couldn’t you run them as part of application startup but before starting handling user input (like e.g. starting the phoenix endpoint)

We don’t have hooks on purpose.

You can run them when your application starts, as proposed by @LostKobrakai. Alternatively, you can add your own script to the bin directory, that you use to run migrations and then start the release. You can do this by adding a step to your mix.exs:

def project do
  [
    ...,
    releases: [
      my_app: [
        steps: [:assemble, &copy_bin_files/1]
      ]
    ]
  ]
end

where:

defp copy_bin_files(release) do
  File.cp_r("rel/bin", Path.join(release.path, "bin"))
  release
end

And you put the extra scripts in rel/bin.

I will examine both approaches. Thank you @LostKobrakai and @josevalim.

I am slightly inclined to “bring scripts with release” method since I would like to decouple scripts from application implementation.

BTW,

I am curious about the rationale here. Simplification, perhaps?

Imo the “steps” abstraction is more powerful and composable. One could probably build a small purpose build library, which handles all the dirty work of such boot hooks and supply its assembly to the steps listed in mix.exs.

Exactly!

So it’s recommended to either call the migrations as mix task during deployment, separately from starting the application now, or maybe I should run the function that does migrations on every application start up?

I honestly don’t see much harm in doing the later but I may be missing something.

Interesting if it could lead to race conditions in a distributed setup. But, well, maybe in such a setup, one does not restart all nodes at the exact same time.

I think migrations run wrapped in a transaction (one transaction per migration if I recall) but yes, that’s a concern since I can imagine situation where with multiple application instances starting up things can go sideways.

Yes, I can confirm that this approach can go sideways. Unwinding the resulting mess as a consultant pays the bills, but I’d rather spend the time creating new stuff. Much better to separate applying migrations from app execution.

To be fair, thinking about it now, I think running migrations on app start up and as post-deploy hook that’d run on all instance is equally bad. So this problem can also happen with distillery / hooks triggering running migrations.