On Wed, Aug 9, 2023 at 10:32 AM Fred Hebert ***@***.***> wrote: Hm, there's something odd here because you're absolutely not relying on hooks anywhere in the config, so I'm a bit confused as to why hook arguments have any bearing there. Particularly, keeping the argument list would likely fix things if tar was seen as anything except a post-hook of release, or unless tar specifies release as a pre-hook (and would break things if tar became a post-hook of say, running tests—which is why this fix isn't ideal), but that's not the way the bug is surfacing here. Checking things step by step: - Tar doesn't seem to rely on release <https://github.com/erlang/rebar3/blob/9ae99e9c5d94a5a3dd37fa6eff22d9a49f3748ca/apps/rebar/src/rebar_prv_tar.erl#L14-L15> and does not specify hooks <https://github.com/erlang/rebar3/blob/9ae99e9c5d94a5a3dd37fa6eff22d9a49f3748ca/apps/rebar/src/rebar_prv_tar.erl#L23-L30> . - The opt spec list carries the term <https://github.com/erlang/rebar3/blob/9ae99e9c5d94a5a3dd37fa6eff22d9a49f3748ca/apps/rebar/src/rebar_relx.erl#L277-L278> so the provider should get it from the command line. - The hooks are run but don't save their state <https://github.com/erlang/rebar3/blob/9ae99e9c5d94a5a3dd37fa6eff22d9a49f3748ca/apps/rebar/src/rebar_relx.erl#L53C36-L53C36> so the omission should not impact the relup task. - The tar task is called directly in relx <https://github.com/erlang/rebar3/blob/9ae99e9c5d94a5a3dd37fa6eff22d9a49f3748ca/apps/rebar/src/rebar_relx.erl#L130-L131> - The picking of the release seems to assume the call sets the relname and version <https://github.com/erlware/relx/blob/8c571fde08aaa2d174e69fb632ba98312f3765a0/src/relx.erl#L110-L128> - The name should be chosen in a common path <https://github.com/erlang/rebar3/blob/9ae99e9c5d94a5a3dd37fa6eff22d9a49f3748ca/apps/rebar/src/rebar_relx.erl#L55> So there's something missing here in how the issue is reported. I tried reproducing it: λ [vps] /tmp → rebar3 new release aaa ===> Writing aaa/apps/aaa/src/aaa_app.erl ===> Writing aaa/apps/aaa/src/aaa_sup.erl ===> Writing aaa/apps/aaa/src/aaa.app.src ===> Writing aaa/rebar.config ===> Writing aaa/config/sys.config ===> Writing aaa/config/vm.args ===> Writing aaa/.gitignore ===> Writing aaa/LICENSE.md ===> Writing aaa/README.md λ [vps] /tmp → cd aaa λ [vps] aaa → vim rebar.config λ [vps] aaa → cat rebar.config {relx, [{release, {aaa, "0.1.0"}, [aaa, sasl]}, {release, {bbb, "0.1.0"}, [aaa, sasl]}]}. λ [vps] aaa → rebar3 do release --relname bbb, tar --relname bbb ===> Verifying dependencies... ===> Analyzing applications... ===> Compiling aaa ===> Assembling release bbb-0.1.0... ===> Release successfully assembled: _build/default/rel/bbb ===> Verifying dependencies... ===> Analyzing applications... ===> Compiling aaa ===> Assembling release bbb-0.1.0... ===> Release successfully assembled: _build/default/rel/bbb ===> Building release tarball bbb-0.1.0.tar.gz... ===> Tarball successfully created: _build/default/rel/bbb/bbb-0.1.0.tar.gz So at least, the command works exactly as advertised. Can you provide at least your hook specification to match here? Specifically though, if we want to fix it for hooks (which is a valid concern), the fix needs to be a bit more careful. For one, rather than looking only at the hook's provider (tar in your fix, which makes me believe you're using it as a post-hook to release), we would likely want to check that the tar post-hook is paired with the release Command, and that the release pre-hook is paired with the tar Command. This will at least prevent crashes when trying to run commands with different configuration sets. — Reply to this email directly, view it on GitHub <#2814 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFKWMA74MYXBUMJOSFET53XUONOPANCNFSM6AAAAAA3ERRN2M> . You are receiving this because you authored the thread.Message ID: ***@***.***>