Internal rebar3 invocation causes crash running `rebar3 grisp-io upload`

[ziopio]

The issue appears on Erlang 28.2 and rebar 3.26.0

rebar3 grisp-io upload
or
rebar3 grisp firmware

===> Compiling grisp_demo
* Deploying bundle...
Args: ["as",
       ["default",",","braid",",","grisp"],
       "grisp","deploy","--tar","--relname","grisp_demo","--relvsn","1.2.0",
       "--destination", []]

Error: {case_clause,[]}
[{rebar_utils,rest_arg_self_contains_comma,1,
              [{file,"/private/var/folders/_z/j32x_t_s13j70f97g_jj9c780000gn/T/rebar3-3.26.0/apps/rebar/src/rebar_utils.erl"},
               {line,956}]},
 {rebar_utils,arg_or_flag,2,
              [{file,"/private/var/folders/_z/j32x_t_s13j70f97g_jj9c780000gn/T/rebar3-3.26.0/apps/rebar/src/rebar_utils.erl"},
               {line,917}]},
 {rebar_prv_as,comma_or_end,2,
               [{file,"/private/var/folders/_z/j32x_t_s13j70f97g_jj9c780000gn/T/rebar3-3.26.0/apps/rebar/src/rebar_prv_as.erl"},
                {line,94}]},
 {rebar_prv_as,do,1,
               [{file,"/private/var/folders/_z/j32x_t_s13j70f97g_jj9c780000gn/T/rebar3-3.26.0/apps/rebar/src/rebar_prv_as.erl"},
                {line,35}]},
 {rebar_core,do,2,
             [{file,"/private/var/folders/_z/j32x_t_s13j70f97g_jj9c780000gn/T/rebar3-3.26.0/apps/rebar/src/rebar_core.erl"},
              {line,155}]},
 {rebar3,run_aux,2,
         [{file,"/private/var/folders/_z/j32x_t_s13j70f97g_jj9c780000gn/T/rebar3-3.26.0/apps/rebar/src/rebar3.erl"},
          {line,212}]},
 {rebar3_grisp_firmware,deploy_bundle,5,
                        [{file,"/Users/lucasucci/Desktop/grisp/grisp_demo/_checkouts/rebar3_grisp/src/rebar3_grisp_firmware.erl"},
                         {line,194}]},
 {rebar3_grisp_firmware,get_bundle,5,
                        [{file,"/Users/lucasucci/Desktop/grisp/grisp_demo/_checkouts/rebar3_grisp/src/rebar3_grisp_firmware.erl"},
                         {line,166}]}]

It looks like the fact that we pass an empty list as argument breaks the arg parsing logic in rebar3

[ziopio]

The error seams to be related to

rebar3_grisp/src/rebar3_grisp_firmware.erl

Line 185 in c798ddc

"--destination", ""

passing an empty list gives problems with the latest rebar.
Since deploy handles the undefined destination value, I found a partial solution in deleting this line.

But I also noticed a second problem:
Since grisp-io upload uses firmware and firmware uses deploy, The deploy command will execute the pre_script and post_script that are present in the project grisp configuration.

This happens for example with grisp_demo

grisp_demo % rebar3 as stage grisp-io upload
===> Analyzing applications...
===> Compiling rebar3_grisp
===> Analyzing applications...
===> Compiling rebar3_grisp
Local password >                         
* Building software package...           
...
===> Compiling grisp_demo
* Building system firmware...
...
* Deploying bundle...
Args: ["as",
       ["default",",","stage",",","grisp"],
       "grisp","deploy","--tar","--relname","grisp_demo","--relvsn","1.3.0"]
===> Compiling grisp_demo
* Resolving OTP version
    28.3.1 (requirement was "28")
* Using pre-built OTP package (97bd8a12)
    (file cached)
* Extracting package
    (already extracted)
===> Assembling release grisp_demo-1.3.0...
===> Release successfully assembled: _build/stage+grisp/rel/grisp_demo
* Bundling release...
* Bundling files...
* GRiSP deploy bundle archived in _grisp/deploy/grisp2.grisp_demo.1.3.0.stage.tar.gz
* Running copy pre_script
===> Missing directory: /Volumes/GRISP

[ziopio]

@GwendalLaurent @sylane, what do you suggest to do with pre and post scripts?

IMO, it would make sense to disable them when we are deployng to a bundle as their main purpose is to clean and unmount the SD card of a standard deployment.

[GwendalLaurent]

If I understand correctly, pre and post script could contain any shell script. Is that correct ?

If it's the case, one could use them for a different purpose than just clean and unmount the SD card.

[ziopio]

If we leave them there, then the user will have to figure this out, guessing that we are using the deploy command and that he needs to adjust config if he wants to generate a firmware.

[ziopio]

The annoyng thing about my workflow, is that: if I test a software version in the SD card, then when I want to build a package I need to comment out the deploy config in by rebar.config

[ziopio]

@GwendalLaurent this could be an idea, disable the whole deploy config section if asembling a bundle.
We would need of course to document this exception...

[ziopio]

If I understand correctly, pre and post script could contain any shell script. Is that correct ?

If it's the case, one could use them for a different purpose than just clean and unmount the SD card.

Tecnically the context of these hooks is to run before and after copyng to the desired destination. So the commands are for acting around this copy. In case we build a bundle, we controll the destination, so realistically, the user commands will not be usefull or even problematic.

[ziopio]

Fixed in #109