fix(config): add missing enum constructors for `shared_subscription_strategy`
Currently, there's [code](048afa6d2d/apps/emqx/src/emqx_shared_sub.erl (L270-L279)) and tests that expect the possibility of
values `sticky`, `hash_topic` and `hash_clientid` in the
`node.shared_subscritpion_strategy` configuration, but the schema enum
does not contain those constructors.
There's also a `hash` constructor expected, but apparently it's just for backwards compatibility (same as `hash_clientid`), so maybe we can skip it in 5.0
Currently, there's code and tests that expect the possibility of a
value `sticky`, `hash_topic` and `hash_clientid` in the
`node.shared_subscritpion_strategy` configuration, but the schema enum
does not contain those constructors.
Keeping headers in the src directory makes sense for the interfaces we
don't want to expose outside, but the `include_lib` directive fails to
compile under Mix. Changing `include_lib("emqx_gateway/src/...")` to
`-include("src/...")` pleases both Mix and Rebar.
chore(update_appup): Improve `update_appup.escript` (5.0)
Port of #6480 .
* Make the script regex-aware
This change makes the `update_appup.escript` check whether the new
version of an application (the _current_ one) is already contained in
entries in the _new_ .appup file for that application if such .appup
file contains regexes.
* Do not use `load_module` instructions if `restart_application` is present
Since the appup instruction `restart_application` already loads all
modules of a given application, there is no need to introduce those
instructions if a restart is already present.
* Do not force `.appup.src` render if contents are the same
To avoid losing comments and/or manual indentation in appup files that
are already up to date, we now check whether the contents have the
exact same terms as those we are about to write to an existint .appup
file.
* Insert `load_module`s after `application:stop`, if present
If there is already any `application:stop(Application)` call in the
appup instructions, we prefer to add `load_module` instructions after
it, so we can be sure that the load is replaced safely.
* Add expected versions check
For apps inside emqx umbrella, we try to bump only the patch part of
their version numbers, and use only 3-part version
numbers (`Major.Minor.Patch`). With those assumptions, we may infer
all versions that need to be covered in a given upgrade, and check if
those are covered in regexes.
fix(bin_emqx): remove `vm_args` backup in `install`
The `install_upgrade.escript` depended on being able to retrieve the
`vm_args` argument from `init`, but that options has been removed
recently. Since this backup was unused, we also remove it here.
Also, the `cuttlefish` script reference is removed, since it is no longer
present in the release.
Port of #6480 .
* Make the script regex-aware
This change makes the `update_appup.escript` check whether the new
version of an application (the _current_ one) is already contained in
entries in the _new_ .appup file for that application if such .appup
file contains regexes.
* Do not use `load_module` instructions if `restart_application` is present
Since the appup instruction `restart_application` already loads all
modules of a given application, there is no need to introduce those
instructions if a restart is already present.
* Do not force `.appup.src` render if contents are the same
To avoid losing comments and/or manual indentation in appup files that
are already up to date, we now check whether the contents have the
exact same terms as those we are about to write to an existint .appup
file.
* Insert `load_module`s after `application:stop`, if present
If there is already any `application:stop(Application)` call in the
appup instructions, we prefer to add `load_module` instructions after
it, so we can be sure that the load is replaced safely.
* Add expected versions check
For apps inside emqx umbrella, we try to bump only the patch part of
their version numbers, and use only 3-part version
numbers (`Major.Minor.Patch`). With those assumptions, we may infer
all versions that need to be covered in a given upgrade, and check if
those are covered in regexes.
The `install_upgrade.escript` depended on being able to retrieve the
`vm_args` argument from `init`, but that options has been removed
recently. Since this backup was unused, we also remove it here.
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`).
While declaring `emqx_conf` as an application dependency of
`emqx_resource` worked for releases, it messed up the startup
relationship during tests. Since only removing `emqx_conf` from the
`applications` key in `emqx_resource` breaks the list of apps that
need to be rebooted on config changes (since `emqx_conf` is not on any
apps dependencies list, it was not being added to the final
topologically sorted list), we now always add it as a vertex to ensure
its presence there. This (apparently) makes the rebar3 release, the
mix release and test runs behave normally.
