Overrides for dependency appups

[jwheare]

Dependencies very rarely include appups. It often doesn't really make sense because you can only provide an upgrade between specific versions (or a regex match) and the modules that need to be unloaded/reloaded can vary a lot between 1.0 -> current and 2.0 -> current, etc.

So, usually what you have to do if you're using release upgrades is: fork the dependency and add your own custom appup.

So I was very excited to find this plugin, however, it can struggle with generating a correct appup, especially with complex supervision trees, so it can't really be trusted in an automated CI build situation. It's fine for your own apps because you can just commit the appups into your own project, but not so for deps (without forking).

So, yeah, this is mainly an issue where releases and upgrades are built by a ci job, as if you're running a release manually you can obviously edit the generated appups before tarring it.

One way to workaround this is for the parent project to be able to provide its own appups for a dependency that can be committed into its own source repo. In the past we have used something like this:

Set a hook in rebar.config

% can be used to inject appup files. script inherits lots of rebar env vars.
{pre_hooks, [
    {release, "./support/rebar_hooks/pre_release.sh"}
]}.

pre_release.sh:

#!/bin/bash -e

# Looks for .appup files in a folder called dep_appups and installs them
# in the rebar dep ebin before release
for appup in dep_appups/*.appup; do
    dep=$(basename $appup .appup)
    ebin="$REBAR_DEPS_DIR/$dep/ebin"
    target="$ebin/$dep.appup"
    test -d "$ebin" || continue
    echo "===> Installing $appup in $target"
    cp "$appup" "$target"
done

You still have to go in and generate an appup for each dep, so it might be nice if this plugin could generate the initial appup for you as a template to tweak.

---

Related to this, it might be nice to add the ability to specify a simpler appup generation algorithm for certain deps, where just loading all the modules and restarting the application would work fine.

For example, the place I encountered auto-generation failing was upgrading between this diff lpgauth/statsderl@v0.3.5...0.5.2

It ended up adding 8 generate_supervisor_child_instruction pairs for each of the dynamically generated children, but using the module name rather than their dynamic names. In this case an application restart would have been better. Let me know if I should file an issue for this.

[lrascao]

How about if the plugin picks up .appup.src files and deploys them to the corresponding application? You would, for example, keep a foo.appup.src file in your bar application, the plugin would then validate the appup file and copy it to the foo application, this would be an implicit mechanism but it has the advantage of being simple to use.

Regarding the simpler appup generation, could you please submit a different issue? It's just easier to keep the discussion to the point this way, thanks!

[jwheare]

Yup I think that would work well.

[lrascao]

closing via #19