Prior to EMQX 5.0, the edge edition's main difference comaring
to standard edition are:
* Less number of plugins in the release (smaller package size)
* Smaller number is vm.args (for lower memory usage)
Starting from 5.0 most of the plugins are included as features,
the tuned vm.args arguments does not justify a special release edition.
Also as nanomq is getting mature,
EMQ's recommendtation for MQTT broker in edge is https://nanomq.io/
This commit adds a function to the rule engine that alows users
to transform text or JSON objects using [jq filter programs][1].
[jq][1] is a command line tool that can be used to transform
and filter JSON text using jq's built-in language. The rule engine
function that is added with this commit uses the
[Erlang jq NIF library][2] that wraps the jq C library in an
Erlang NIF function.
[1]: https://stedolan.github.io/jq/
[2]: https://github.com/emqx/jq
chore(mix): use MIX_ENV to define build profile and edition
Instead of reading some environment variables to define the build profile for the Elixir build, we use the MIX_ENV value to emulate Rebar3's profiles. Also, that makes the build output directory more similar to EMQ X's current scheme.
- Secure tests on master branch after merge.
- Improve build cache hit rates
Due to security reason, github only allow reuse cache from
- same branch
- base branch
- default branch
Branch Feature-A could not reuse the cache from Feature-B
- Developers could run the workflow in their own forked repo
before make the PR, this could relieve the runners on upstream repo
The RLOG DB backend tests in FVT were temporarily disabled due to some
paho tests being specially flaky in CI.
In particular, those tests had the common pattern of subscribing to a
topic, immediately publishing to that topic and then waiting for the
response. When in CI and using RLOG, there seems to be more delays in
replication of data, and often this pattern would fail in the
constraint testing enviroment.
A few FVT tests are very flaky when run in rlog core+replicant cluster
configuration (for instance `V5/test_publish.py::test_topic`). We are
disabling this test configuration temporarily while we investigate
further and mitigate it.
there seems to be race conditions related to some tests with sessions
hitting the core and the replicant alternately and rlog.
for intance, if there is some delay in this replication, a new
connection made to the replica with a just-created session in the core
may not have been replicated to the replicant, resulting in a test
failure if it expects the session to be present.
since such replication lags are inherent to the core-replicant
topology, we can try to target only the replicant to avoid seeing this
inconsistent view of the system during the tests.
This parameterizes the Functional Verification Tests (FVTs) that run
in CI to use a replication log (RLOG) role of "replicant" for one of
the nodes. With this addition, our FVTs may explore more scenarios
with data replication.
Ivan Dyachkov