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

Fail loudly on error when executing a cmd in an app.src vsn #2543

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

aronisstav
Copy link
Contributor

@aronisstav aronisstav commented Apr 22, 2021

This PR fixes a bug.

Description
When running rebar3 compile on a strange environment (Windows...), a cmd command in a vsn attribute in an .app.src file failed.

Expected behaviour
An error is prominently displayed.

Actual behaviour
The error was only available with DEBUG=1 and localizing it to the vsn attribute took quite some further digging.

Additional info
While at it, make it so that {abort_on_error, Msg} ALSO shows the error that generated it, indiscriminately. This is a little breaking, but should be a good thing.

I think that this PR is good enough as-is. I might have time to also add a test, if someone kindly points out specifically where.

Copy link
Collaborator

@ferd ferd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you show the expected difference between the old output and the new one? I'm having a bit of a hard time just tracing in my mind what the difference in output is expected to look like.

@@ -792,7 +798,8 @@ vcs_vsn_cmd(_, _, _) ->
unknown.

cmd_vsn_invoke(Cmd, Dir) ->
{ok, VsnString} = rebar_utils:sh(Cmd, [{cd, Dir}, {use_stdout, false}]),
ErrorOpt = {abort_on_error, "vsn cmd in .app.src failed"},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the error message takes place this deep, then it would make sense not to make assumptions on what the caller was doing ("was it really called in a .app.src file?") and simply report the error at its own level (something like "Command x failed") to prevent misguiding error messages when the callsites are expanded.

If we want to provide contextual errors with high-level concerns, then we would need to put in a conditional here and return {ok, VsnString} | {error, Term} and move the reporting to the parent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you clarify a little bit? I am guessing you mean that this code could be reached in different ways, but my understanding, without really checking, is that the only way to reach cmd_vsn_invoke/2 is when really evaluating a cmd in a vsn property, in an .app.src file, which is what my error message reports.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is more of future-proofing. I.e. the function cmd_vsn_invoke knows it is about a version, but has no idea it actually comes from a .app.src file.

@aronisstav
Copy link
Contributor Author

Can you show the expected difference between the old output and the new one? I'm having a bit of a hard time just tracing in my mind what the difference in output is expected to look like.

Right, I forgot!

Before:

❯ cat src/foo.app.src                    
{application, foo,
 [{description, "An OTP application"},
  {vsn, {cmd, "false"}},
  {registered, []},
  {mod, {foo_app, []}},
  {applications,
   [kernel,
    stdlib
   ]},
  {env,[]},
  {modules, []},

  {licenses, ["Apache 2.0"]},
  {links, []}
 ]}.


❯ rebar3 compile                                   
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling foo

❯ echo $?                                             
1

❯ DEBUG=1 rebar3 compile                                 
===> Expanded command sequence to be run: [app_discovery,install_deps,lock,compile]
===> Running provider: app_discovery
===> Found top-level apps: [foo]
	using config: [{src_dirs,["src"]},{lib_dirs,["apps/*","lib/*","."]}]
===> Running provider: install_deps
===> Verifying dependencies...
===> Running provider: lock
===> Running provider: compile
===> Compile (apps)
===> Running hooks for compile with configuration:
===> 	{pre_hooks, []}.
===> Compile (project_apps)
===> Running hooks for compile in app foo (/Users/stavros/sandbox/foo) with configuration:
===> 	{pre_hooks, []}.
===> Running hooks for erlc_compile in app foo (/Users/stavros/sandbox/foo) with configuration:
===> 	{pre_hooks, []}.
===> Analyzing applications...
===> Compiling foo
===> compile options: {erl_opts, [debug_info]}.
===> files to analyze ["/Users/stavros/sandbox/foo/src/foo_sup.erl",
                              "/Users/stavros/sandbox/foo/src/foo_app.erl"]
===> Running hooks for erlc_compile in app foo (/Users/stavros/sandbox/foo) with configuration:
===> 	{post_hooks, []}.
===> Running hooks for app_compile in app foo (/Users/stavros/sandbox/foo) with configuration:
===> 	{pre_hooks, []}.
===> sh(false)
failed with return code 1 and the following output:

After:

❯ rebar3 compile                           
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling foo
===> vsn cmd in .app.src failed
sh(false)
failed with return code 1 and the following output:

@@ -792,7 +798,8 @@ vcs_vsn_cmd(_, _, _) ->
unknown.

cmd_vsn_invoke(Cmd, Dir) ->
{ok, VsnString} = rebar_utils:sh(Cmd, [{cd, Dir}, {use_stdout, false}]),
ErrorOpt = {abort_on_error, "vsn cmd in .app.src failed"},

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to add the actual filename or path here as well. Otherwise, if you have many apps its up to the user to find the one with the bad vsn command

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

Successfully merging this pull request may close these issues.

3 participants