Phoenix hot deployment static assets not using new version

[midas]

When using exrm to build releases for a Phoenix application (https://excasts.com), after the upgrade is complete, it seems that the static assets being used are not the new set. I am using Phoenix digesting in my application.

Paul, just a reminder from our conversation at ElixirConf, you theorized this may be related to the way Phoenix accomplishes its static asset serving. possibly their responsible server does not implement the code_change function.

Thanks and I look forward to working on this issue with you.

[keichan34]

In my application, I usually make an asset_cache_bust/0 function:

def asset_cache_bust do
  Phoenix.Config.clear_cache MyApp.Endpoint
  Phoenix.Endpoint.Adapter.warmup MyApp.Endpoint
end

Then, as part of the deploy script, I use a RPC to call it.

$ /mnt/app/bin/my_app rpc Elixir.MyApp asset_cache_bust

This is obviously a workaround that shouldn't be there, but it works for me. 😃

[bitwalker]

@midas I think I may have found the problem, in Phoenix's config/config.exs, the following configuration is present:

config :my_app, MyApp.Endpoint,
  ...
  root: Path.expand("..", __DIR__),
  ...

The problem here is that root ends up expanding to an absolute path to the project directory when the release is built, so even when you do an upgrade, it's still pointing to the assets via that absolute path.

I overrode it in my example chat app I used in my talk at ElixirConf, by putting the following in config/prod.exs:

config :chat, Chat.Endpoint,
  ...
  root: ".",
  ...

I then tested a style change with a rolling upgrade, and it worked exactly as expected. On the plane home I tried playing around with that setting a bit to try and find something that would work both with releases and without, but couldn't come up with a simple solution. I'm also not 100% sure that this was the problem you had (because the "bug" I found is dependent on an absolute path in the config), but depending on your deployment setup, it's entirely possible this was the culprit.

/cc @chrismccord

[chrismccord]

Would dropping a comment above the config that mentions root for releases be enough? We do similar comments for prod config around starting the web server.

[midas]

@bitwalker That seems plausible to me. Will test on my end. @chrismccord Want me to send a pull request for this comment addition? I would love to get my first contribution in place.

Thanks gentlemen!

[chrismccord]

@midas Please do!

[midas]

@bitwalker Can you expand on the reason why this solution works so that I can explain a little more in depth? Is the root directory of the built release truly .?

[bitwalker]

@midas Sure! The reason it works is because when the configured path is read in the release, it will be done so relative to the application directory in the release (the currently installed version that is). So since the current working directory is already the desired directory for root, we can just set it to ..

[midas]

@chrismccord What effect will a root path of . have on the development environment? Should this setting be overridden only in environments that will be built into a release, ie. production?

Thus, do you think this comment should be in config/config.exs or config/prod.exs?

[bitwalker]

It should go in prod.exs, and the problem with just making the default . is that with mix it only works when running the project from the project root directory. If you are running an umbrella project, or the current working directory is not the project root, it will be incorrect, which I assume is why the default is what it is today, but @chrismccord would have to chime in on that bit.

I think by documenting that root needs to be configured when using releases in prod.exs, we can at least make sure nobody else gets bit by this. It would be nice if there was a more general solution so that root needn't be configured at all though.

[bitwalker]

@midas Is this resolved on the exrm side from your point of view? Can I close this for the time being?

[midas]

I think so. Thanks again!