prior to this change, the OTP_VSN varaible was taken from
the docker host's OTP version which may differ from the
desired OTP version for the docker builder image.
In CI, the source code is downloaded with make deps-all
zipped and uploaded as an GitHub action artifact to be
downloaded in later steps to build packages
The symlinks are abs paths, meaning it might be broken
when unziped (inside docker containers)
This fix adds a `make clean` step after the deps-all target
and the `clean` target also removes rebar.lock and symlinks
The defulat docker build (e.g. make emqx-docker) is based on alpine
image and it builds EMQ X from source code.
This is not flexible enough when we want to quickly run some tests
in a docker container.
The new docker build (e.g. make emqx-docker-testing) by default takes
the built zip package, and extract it in a very primitive base image
such as ubuntu:20.04 and centos:8
This rebar3 version has two fixes comparing to 3.14.3-emqx-5
1. For elixir plugin build, ensure vsn in app info
2. Error details in rebar3 exception if .app is not found
when generating release
Doing release directly works fine for prue Erlang dependencies.
However if we add a elixir dependency, the application
info and release becomes problematic
Elixir apps do not have .app or .app.src files
so the app vsn can not be found during app discovery
which leads to "No valid version ([]) of .app file found"
error when creating the release.
This is maybe fixed in https://github.com/erlang/rebar3/pull/2518
Another issue is "Undefined applications: [elixir,logger]"
This seem to be caused by the rebar3 not being able to identify
as a release dependency if an elixir app was not compiled before.
* chore(Makefile): Delete unnecessary exports for deps-get
* chore(rebar3): upgrade to rebar3 version 3.14.3-emqx-5
This rebar3 version does not copy .git directory.
Before this, if a plugin repo clone is placed in lib-extra,
rebar2 ct or eunit commnad may fail at source code copy step.
zhanghongtong