Surprisingly enough, by doing small cirurgical changes in the existing
EMQX control scripts, we are able to get it running with Elixir and
with existing functionalities (`console`, `remote_console`, `start`,
`stop`, `ctl`, `foreground`, `eval`).
By treating the apps in the umbrella as dependencies to be managed and
built by rebar3, we can simplify the maintenance of the release, at
the cost of increased build times: using Mix as before, it could track
changed files better than using rebar. But the complexity and
possibility of discrepancies make it using rebar much more compelling.
Since Mix does not support hot upgrades out of the box, it does not
create a `RELEASES` file by default. Here, we introduce functionality
similar to what `relx` does in order for that file to be generated.
fdc8d7237e/src/rlx_assemble.erl (L928-L948)
The `RELEASES` file, in its turn, is required for `nodetool` to work
properly, and `nodetool` is required for us to generate several
required config files using `hocon`. Since the `start{_clean}.boot`
file used by the files generated by Elixir must be explicitly defined
in the `RELEASE_LIB` `boot_var`, we apply a small patch in the
existing `nodetool` in order to inject that required parameter when
calling the escript.
This commit enables a minimal working build of EMQX release using
Mix. However, to properly start the release, several configuration
steps are still missing. A `mix_release.sh` script does a few hacks
to get the release built with Mix to start properly, by first assuming
that `make emqx` has been run prior to the release, ran once to
generate the `app.*.config` files, and then it copies that and some
other files to the expected places.
Also, `emqx_telemetry` hangs the start procedure because it thinks
it's in an official release and tries to make a request. We disable
it temporarily via config just to get a working build for now.
Thales Macedo Garitezi