Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relx is ignored when using Rebar3 3.23.0 #2908

Open
tduccuong opened this issue Aug 1, 2024 · 3 comments
Open

Relx is ignored when using Rebar3 3.23.0 #2908

tduccuong opened this issue Aug 1, 2024 · 3 comments

Comments

@tduccuong
Copy link

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
Copy link
Collaborator

ferd commented Aug 29, 2024

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
Copy link
Author

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
Copy link
Collaborator

ferd commented Aug 29, 2024

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 erlang/otp#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 (#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants