[Question] Umbrella - versioning - release updates

[colindensem]

I'm experimenting with a clean-ish umbrella app. Two apps, the core ( domain & db ) and a phoenix web app. A straight up initial deploy works fine and pushing produces suitable log noise to the effect it's released successfully and unpacked, made the 'release' permanent.

I'm using the git log version number in the umbrella project. The apps are fixed at 0.0.1 etc.
If I do a html change for example then push all as expected, log below. At this point, refreshing the app, there is no change. If I issue a /etc/init.d/briskoda_platform stop and start it loads, but still the old code.

This is the tail of the output:

remote: $ mix release --upgrade --upfrom=0.0.1484065140 --warnings-as-errors --env=prod (/home/colin/briskoda_platform)
remote: ==> Assembling release..
remote: ==> Building release briskoda_platform:0.0.1484065756 using environment prod
remote: ==> Including ERTS 8.2 from /usr/lib/erlang/erts-8.2
remote: ==> Relup successfully created
remote: ==> Packaging release..
remote: ==> Release successfully built!
remote:     You can run it in one of the following ways:
remote:       Interactive: rel/briskoda_platform/bin/briskoda_platform console
remote:       Foreground: rel/briskoda_platform/bin/briskoda_platform foreground
remote:       Daemon: rel/briskoda_platform/bin/briskoda_platform start
remote: $ mix ecto.migrate (/home/colin/briskoda_platform/apps/briskoda)
remote: 
remote: 16:29:54.274 [info]  Already up
remote: $ service briskoda_platform upgrade 0.0.1484065756
remote: Release 0.0.1484065756 not found, attempting to unpack releases/0.0.1484065756/briskoda_platform.tar.gz
remote: Unpacked successfully: "0.0.1484065756"
remote: Release 0.0.1484065756 is already unpacked, now installing.
remote: Installed Release: 0.0.1484065756
remote: Made release permanent: "0.0.1484065756"

Looks good.

If I touch the individual apps mix.exs to be 0.0.1 > 0.0.2 I get the appropriate appup file but again no hot reload.

remote: ==> Including ERTS 8.2 from /usr/lib/erlang/erts-8.2
remote: ==> Generated .appup for briskoda 0.0.1 -> 0.0.2
remote: ==> Generated .appup for briskoda_web 0.0.1 -> 0.0.2
remote: ==> Relup successfully created
remote: ==> Packaging release..
remote: ==> Release successfully built!
remote:     You can run it in one of the following ways:
remote:       Interactive: rel/briskoda_platform/bin/briskoda_platform console
remote:       Foreground: rel/briskoda_platform/bin/briskoda_platform foreground
remote:       Daemon: rel/briskoda_platform/bin/briskoda_platform start
remote: $ mix ecto.migrate (/home/colin/briskoda_platform/apps/briskoda)

At this point a manual stop and start works, the new code boots.

At this point having gone over things; issues here; issues on distillery; code etc, I'm at a loss for what I've missed. This is the greatest clue but those steps are covered of by the gatling process.
mix release --upgrade --upfrom=0.0.1484065140 --warnings-as-errors --env=prod

Anyone else got a simple umbrella app hot reloading?

[colindensem]

I've setup a fork of the oxo_umbrella to see if it was the project.
https://github.com/colindensem/oxo_umbrella
Accepting I've followed/copied the same steps. However this also does not work till the mix version bumps and a stop/start cycle... still an improvement on capistrano ;).

[colindensem]

Cleaned down. Repeated. I've put the committed_at version stamp on each of the child applications.

  def project do
    [app: :oxo,
     version: "0.1.#{Oxo.Platform.Mixfile.committed_at}",

Perhaps obviously, this works. The miracle of sleep. I can see myself bumping the minor release when I push to production, but each minor for each feature I push to staging to preview, seems for a manual task to remember, a step I'd prefer not to take.

So if I may adapt the question, is this a sane approach?

If I've not altered the core application, it's getting a version bump anyway this way. My gut is saying roll with this till it's problem, along with a PR to the readme for umbrella's specifically. Thoughts?

Footnotes
The use of the Oxo.Platform.Mixfile.committed_at errors when migrating by way of calling the oxo (db) app directly. Will also cause issues with mix test in each app... Duplicate committed_at in each mix??

Other considerations for umbrella is the npm like tasks in deploy and upgrade. Either alias or append paths.

  def before_mix_digest(env) do
    bash("npm", ~w[install], cd: Path.join(env.build_dir, "apps/yourapp_web"))
    bash("npm", ~w[run deploy], cd: Path.join(env.build_dir, "apps/yourapp_web"))
  end

[colindensem]

Notes for myself; others, this article has a nice tweak on the version numbering.
http://crypt.codemancers.com/posts/2016-10-06-elixir-phoenix-distillery/
Essentially:

export APP_VERSION=`date +%Y.%m.%d%H%M`

Then in mix files

version=System.get_env("APP_VERSION")

I'm not certain that's better, easier, but maybe not as traceable compared to git log bits. Perhaps ideal for the top level or child, but not both.