-
Notifications
You must be signed in to change notification settings - Fork 517
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
Unable to build tar with relname different to app name #2814
Comments
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 Checking things step by step:
So there's something missing here in how the issue is reported. I tried reproducing it:
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 ( |
So it appears you're correct.
We have
```
{provider_hooks,
[{pre, [{tar, {appup, tar}}]},
{post, [{compile, {appup, compile}},
{clean, {appup, clean}}]}]}.
```
It appears that the `pre` hook there is the issue. Will have to do some
research as to why this is here.
…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:
***@***.***>
|
I'm busy upgrading rebar3 from a much older version.
When building a
tar
with a--relname
different to the application name the building of the tar fails as it's looking at the wrong path.Config snippet
When running
rebar3 as prod_node release -n smd_node
works fine and the smd app is built and ends up at_build/prod_node/rel/smd_node
When running
It appears this is due to commit
71e497146
where command_args and command_parsed_args are being removed from the state.I can understand the reasoning, but this makes it impossible to use relname for tars where the application name and the release name do not match.
Would it make sense to not remove relname from the command args?
The text was updated successfully, but these errors were encountered: