Hot reloading an umbrella app with distillery

Questions / Help
1

I am trying to get hot code reloading with distillery releases to work in my umbrella app.

The steps executed are:

On build server:

$ MIX_ENV=prod mix compile
$ MIX_ENV=prod VERSION=2.2.0 mix release --env=prod --upgrade

The release builds successfully and then is fetched from the build server and uploaded to all app servers.

On the app servers:

$ /tmp/myapp/bin/myapp upgrade "2.2.0"

The release is unpacked and successfully switched to.

I can tell that the config is reloaded, because the version of the app changes (I have a view that lets me see the version that is stored in a config file, which uses the env variable at compile time).

However, none of the actual source code in the apps folder seem to change. I can, for example, create a new function, create a release for it, upgrade to that release, and the function will not exist. However, if I take that exact same release and use it to start the app from scratch, the new function will exist.

Help! :slight_smile:

1 Like
2

Hi there! Could you paste the .appup files which are generated by Distillery? Those will tell us what it’s generating for upgrade instructions. They should be in _build/<env>/lib/*/ebin/. You’ll want to find each appup which you are expecting to see changes in.

I suspect that the problem is that the upgrade is applied successfully, but the changes is basically just an empty list. So the code isn’t being upgraded, but configuration is. This probably means the appup generator isn’t doing something right with umbrella apps, although I’m not sure why that would happen. It could also be for some perfectly legitimate reason, but we’ll have to narrow things down a bit to know for sure :slight_smile:

1 Like
3

Interesting, there don’t seem to be any files called .appup after building an upgrade release.

4

That’s strange. Could you run find _build -name '*.appup' to be sure? There should also be something in the verbose logs (enabled with --verbose) which mention any appups which are generated.

5 
_build/prod/rel/hydrogen/lib/crypto-3.7/ebin/crypto.appup
_build/prod/rel/hydrogen/lib/compiler-7.0/ebin/compiler.appup
_build/prod/rel/hydrogen/lib/kernel-5.0/ebin/kernel.appup
_build/prod/rel/hydrogen/lib/xmerl-1.3.11/ebin/xmerl.appup
_build/prod/rel/hydrogen/lib/ssl-8.0/ebin/ssl.appup
_build/prod/rel/hydrogen/lib/asn1-4.0.3/ebin/asn1.appup
_build/prod/rel/hydrogen/lib/stdlib-3.0/ebin/stdlib.appup
_build/prod/rel/hydrogen/lib/public_key-1.2/ebin/public_key.appup
_build/prod/rel/hydrogen/lib/sasl-3.0/ebin/sasl.appup

None of these are apps in my umbrella apps folder.

I also don’t see any mention of appups in the verbose output after running: MIX_ENV=prod VERSION=2.4.0 mix release --env=prod --upgrade --verbose

6

Could you paste your verbose logs? I’ll do some digging.

7

So I think I figured out the problem.

I was using environment variables to set the version numbers of all my mix.exs files, and this meant no changes were being picked up in the releases. The version number was being picked up in my config file, which is why I thought it should work. Example mix config:

def project do
    [
      app: :rest_api,
      version: System.get_env("VERSION") || "2.0.0"
...

Is there a way I can use some sort of dynamic versioning but still pick up changes? Is using an env variable that different from using a git-based version?

I’m hesitant to use git because I’d like to be able to push releases without making a commit - for example, a config change.

8

Interesting, I’ll have to experiment with that, because I’m not sure why that wouldn’t work the way you’ve shown. Perhaps there is something I can do in Distillery to fix that. That said, I have something I’d like you to try:

version = System.get_env("VERSION") || "2.0.0"
defmodule MyApp.Mixfile do
  use Mix.Project
  def project do
    [ app: :myapp,
      version: version,
      ... ]
   ...

I think by forcing the evaluation of version when mix.exs is read, it will work the way you expect. But if you could confirm that one way or the other, I think that will help determine what’s going on here.