Post Actions user confirmation

[dansiegel]

After doing some testing with the Post Action to Run a script, specifically to run git init, git add *, and git commit -m "Initial Commit", everything succeeds, but the user is prompted Do you want to run this action (Y|N)? for each command which quickly can become a bad user experience, particularly if you have a lot of post actions running.

At minimum if a particular executable is called more than once, the user should not be asked more than once. Ideally there should be a way to opt out of this. In my particular case I already have a parameter where someone could toggle --git-init true/false so it's already something that the user would have opted to do.

[mlorbetske]

If the user passes --allow-scripts yes (this parameter defaults to prompt), then the prompts will not be displayed. This options should be visible in the template's help if it has script type post-actions. Generally though, we discourage the use of script type post actions as there's usually not a guarantee that the user has support for the command that's being run.

cc @blowdart

[dansiegel]

It's a bit of a hack for now. If there was a git init action like there is for NuGet restore I'd use that instead, and ultimately I would like to open a readme if the project is created in Visual Studio of VS for Mac.

[dansiegel]

@mlorbetske is it possible to condition my post action scripts on the user specifically passing in --allow-scripts yes? I tried updating the logic to either: "condition": "(AllowScripts)" or "condition": "(AllowScripts == \"yes\")" and in both cases the generated help doesn't even show the allow-scripts symbol....

[mlorbetske]

The allow-scripts parameter isn't processed as a template parameter to avoid tampering with the value (imagine being able to set up a run script post action to format the user's hard drive & declare a duplicate symbol that would override the system's default). It would be possible for us to pass the value in to the template's parameter collection and ignore any mutation of that value when doing the processing, but this could lead to (in the case of the malicious example) skipping the attempt to run the bad thing unless the user has explicitly already allowed it (where they wouldn't know it'd be attempted if the post action were always otherwise skipped due to the false condition evaluation).

[mlorbetske]

WRT to --allow-scripts not showing up in help, @seancpeters, can you take a look at that?

[dansiegel]

I'm thinking perhaps a better option here would be to evaluate a template one time like when I install or update the template. If I'm installing a template that has scripts it could alert me and ask me at that time do I want to be prompted each time allow the scripts or disable them. That way I don't get pestered every time I create a new template. Then if the template is updated it could be evaluated to determine if the post action scripts are the same in which case my trust carries over to the update, or if they were updated or new scripts were added in which case I would get prompted again.

[mlorbetske]

That's interesting. We'd have to think about the UX (do we show all possible things that could be run - possibly quite verbose vs that scripts may be run in general - not enough info/how this works once parameterization of post-actions is allowed/etc.) and get blessing from @blowdart, but I think that could make the prompting a bit less obnoxious.

Another option would be to make the prompt quad-state (yes/no/yes-all/no-all) or to summarize all scripts that may be run when the first prompt is encountered & let the user choose whether they want individual prompts (maybe they don't have all the tools to run all of the scripts that would run or will accomplish the same thing manually via a different command).

[seancpeters]

Regarding --allow-scripts not showing up in help, I haven't been able to reproduce the problem. From my testing, and examination of the code, --allow-scripts is displayed in the template help if-and-only-if the template contains a script running post action, i.e. a post action whose:
"ActionId": "3A7C4B45-1F5D-4A30-959A-51B88E82B5D2"

@dansiegel - Could you provide an example template.json containing a script-running post action, but where the --allow-scripts flag does not show up in help?

[seancpeters]

For the issue of having to specify allow-scripts (or be prompted) on every invocation of a template, with #563 a user could setup an alias for a template with --allow-scripts yes as part of the alias specification. For example, if I have installed a template named 'foo', which has post action scripts, I could make an alias:
dotnet new foo -a fooY --allow-scripts yes

Then running dotnet new fooY runs the scripts without user prompting.

[dansiegel]

@seancpeters what I was trying to do was to avoid asking someone twice if they want to do a git initialization on the project by removing my initial symbol and making the post action conditioned on the AllowScripts flag being true. From the feedback that @mlorbetske gave, it sounds like that isn't currently possible and likely why it got ignored since it would always evaluate to false. I would be among the first to say this approach was hacky and not a good long term approach. Ultimately doing a git initialization is probably going to be a common use case and it wouldn't be bad to make it's own pre-defined post action just like NuGet restore. That said, in the event someone does have some other scripts that they want to run it would still be best to clean up the process so you don't get bombarded with prompts when you go to create a new project.

    {
      // Had also tried this as "(AllowScripts =\"yes\")"
      "condition": "(AllowScripts)",
      "description": "Run 'git init'",
      "actionId": "3A7C4B45-1F5D-4A30-959A-51B88E82B5D2",
      "manualInstructions": [
        { "text": "Run 'git init'" }
      ],
      "args": {
        "executable": "git",
        "args": "init"
      }
    }

[donJoseLuis]

the last update on this issue was ~3 years ago. We are working on prioritizing dotnet new ux issues, where priorities are: new items & issues with many votes