Relx is ignored when using Rebar3 3.23.0

[tduccuong]

Environment

$ rebar3 report
Rebar3 report
 version 3.23.0
 generated at 2024-08-01T16:57:20+00:00
=================
Please submit this along with your issue at https://github.com/erlang/rebar3/issues (and feel free to edit out private information, if any)
-----------------
Task: 
Entered as:

-----------------
Operating System: x86_64-pc-linux-gnu
ERTS: Erlang/OTP 26 [erts-14.2.1] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1]
Root Directory: /var/lib/buildbot/erl-build/builds/f43a339ee5853ac8f87c733d1e37898c3b5393f5b64718f24e2f6920bfd52ab0/lib/erlang
Library directory: /var/lib/buildbot/erl-build/builds/f43a339ee5853ac8f87c733d1e37898c3b5393f5b64718f24e2f6920bfd52ab0/lib/erlang/lib
-----------------
Loaded Applications:
bbmustache: 1.12.2
certifi: 2.11.0
cf: 0.3.1
common_test: 1.26
compiler: 8.4.1
crypto: 5.4
cth_readable: 1.5.1
dialyzer: 5.1.2
edoc: 1.2.1
erlware_commons: 1.7.0
eunit: 2.9
eunit_formatters: 0.5.0
getopt: 1.0.2
inets: 9.1
kernel: 9.2
providers: 1.9.0
public_key: 1.15
relx: 4.9.0
sasl: 4.2.1
snmp: 5.15
ssl_verify_fun: 1.1.6
stdlib: 5.2
syntax_tools: 3.1
tools: 3.6

-----------------
Escript path: /path/to/rebar3
Providers:
  alias app_discovery as clean compile compile completion cover ct deps dialyzer do edoc escriptize eunit get-deps help install install_deps list lock manifest new package path pkgs release relup report repos shell state tar tree unlock update upgrade upgrade upgrade vendor version xref 

My rebar.config is as follow:

{profiles, [{prod, [{relx, [
  {release,
    {my_app, "2.1.2"},
    [myapp, sasl, {dep1, load}, {dep2, load}, recon, {os_mon, load}]
  },
  {sys_config_src, "release/sys.config"},
  {vm_args_src, "release/vm.args"},
  {dev_mode, false},
  {include_erts, true},
  {include_src, false},
  {debug_info, strip}
]}]}]}

I am using Erlang 26:

$ rebar3 -v
rebar 3.23.0 on Erlang/OTP 26 Erts 14.2.1

Current behaviour

According to Rebar3 output, the release was created successfully. But there is no myapp.boot file found in the _build folder, hence I could not run my application. I also noticed that these lines were not found in the console output:

===> Starting relx build process ...
===> Resolving OTP Applications from directories:
===> Including Erts from /root/.cache/erls/otps/OTP-22.1/dist/lib/erlang

When I downgrade to use Rebar3 version 3.13.0, the release is created successfully, the .boot file is there, those lines are found in console output.

Expected behaviour

Relx should be triggered and a .boot file should be created.

[ferd]

Uh I had missed this issue going through.

I can't really reproduce on my end. I still find boot files on my end in directories such as _build/$profile/rel/$relname/$version/, namely no_dot_erlang.boot, start.boot, and start_clean.boot.

[tduccuong]

Thanks @ferd, yeah I have those files too (no_dot_erlang.boot, start.boot, and start_clean.boot), but don't have the myapp.boot file. When downgraded Rebar3 to 3.13 like mentioned above, the myapp.boot file is generated. Also, the dist size is significantly larger than generated by 3.23.

Is that normal or I missed something?

[ferd]

It's gonna be a bit challenging to know if it's normal or not, 3.13 is at least 5 years old by now, things changed a bit and we switched a full major relx release in the intervening years.

Some of these changes were also made because fixes were ported upstream to Erlang/OTP to support releases differently (see https://github.com/erlang/otp/pull/2420 for an example).

At this point I'm not quite sure whether this was accidental or on purpose. I'm still running some releases daily and they work fine, so I haven't noticed breakage in end-to-end functionality even if some files may have changed. I imagine some accidental breaking changes are to be expected when Rebar3 3.14 switched to Relx 4.0 in 2020. Some changes in there were bigger and even version handling changed (https://github.com/erlang/rebar3/issues/2846) a bit unexpectedly.

If you are to bisect, at least confirming/eliminating that 3.14.x versions are to blame could narrow it down a good bit.