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

Unable to build tar with relname different to app name #2814

Open
leonardb opened this issue Aug 4, 2023 · 2 comments · May be fixed by #2816
Open

Unable to build tar with relname different to app name #2814

leonardb opened this issue Aug 4, 2023 · 2 comments · May be fixed by #2816

Comments

@leonardb
Copy link

leonardb commented Aug 4, 2023

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

{relx, [{release, {smd, "3.1.0"},
         [{smd, "3.1.0"}, .....],
         [{overlay_vars, "rel/vars/build_date.config"},
          {overlay, [{template, "rel/files/vm.args", "releases/{{release_version}}/vm.args"},
                     {template, "rel/files/smd.config", "releases/{{release_version}}/sys.config"}]},
          {extended_start_script, true}]},

        {release, {smd_node, "3.1.0"},
         [{smd, "3.1.0"}, .....],
         [{overlay_vars, "rel/vars/build_date.config"},
          {overlay, [{template, "rel/files/vm.args", "releases/{{release_version}}/vm.args"},
                     {template, "rel/files/smd_node.config", "releases/{{release_version}}/sys.config"}]},
          {extended_start_script, true}]}
    ]}.
{profiles, [{local,
             [{relx, [{dev_mode, true}
                     , {include_erts, true}
                     , {overlay_vars, "rel/vars/local.config"} ]}]},
            {local_node,
             [{relx, [{dev_mode, true}
                     , {include_erts, true}
                     , {overlay_vars, "rel/vars/local.config"} ]}]},
            {local_core,
             [{relx, [{dev_mode, true}
                     , {include_erts, true}
                     , {overlay_vars, "rel/vars/local.config"} ]}]},
            {prod_core,
             [{relx, [{overlay_vars, "rel/vars/prod_core.config"}
                     , {include_erts, true}
                     , {include_src, false}
                     , {dev_mode, false}
                     , {debug_info, strip}
                     ]}]},
            {prod_node,
             [{relx, [{overlay_vars, "rel/vars/prod_node.config"}
                     , {include_erts, true}
                     , {include_src, false}
                     , {dev_mode, false}
                     , {debug_info, strip}
                     ]}]}
           ]}.

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

leonard@captmarvel:/opt/smd$ rebar3 as prod_node tar --relname=smd_node
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling smd
===> /opt/smd/_build/prod_node/rel/smd/releases/start_erl.data is missing

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?

@ferd
Copy link
Collaborator

ferd commented Aug 9, 2023

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:

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.

@leonardb
Copy link
Author

leonardb commented Aug 9, 2023 via email

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