Stop Boxstarter continuing on first package install failure

[htnhan]

Per @pauby recommendation, I create this question to discuss PR #296. CC @gep13, @mwallner, @flcdrg and @mwrock

@mwallner suggests that my PR will break current BoxStarter behavior with the following case:

cinst something -y
cinst foo -y
cinst bar -y

with the assumption that foo always fails to install. Currently, BoxStarter happily install something, skip foo, and continue to install bar. With my PR, BoxStarter will stops after the fail attempt to install foo.

Unless I miss something, I thought even with my PR, BoxStarter still continues to bar. cinst simply returns a 1 (indicating an error occurs) instead of a 0 (no error) (Boxstarter.Chocolatey/Chocolatey.ps1 line 59, and line 181-184). The installer script has the liberty to decide what happens when BoxStarter fails to install foo: report an error and stop, or log the failed package and continue.

Is my assumption correct?

[pauby]

with the assumption that foo always fails to install. Currently, BoxStarter happily install something, skip foo, and continue to install bar. With my PR, BoxStarter will stops after the fail attempt to install foo.

This is a breaking change. Boxstarter is intended to automate the installation / configuration of a machine. So you:

1. Create a Boxstarter script
2. Have Boxstarter run that script
3. Go away and grab a coffee / get on with some work
4. Come back and the machine is built and in this case the error that package foo could not be installed is flagged up. You can then decide what you want to do (install it again, forget about it etc.).

Your changes mean:

1. Create a Boxstarter script
2. Have Boxstarter run that script
3. Go away and grab a coffee / get on with some work
4. Come back and the machine is not built as the script stopped at package foo with an error

If this breaking change is implemented then the user should be given the choice to stop on errors - the default remaining as it is now and continuing through the errors.
The switch -StopOnError has been suggested.

[simmdan]

For what it's worth, I absolutely need some version of this change. I'm using boxstarter to automate configuration of build machines, and my recent discovery that it wasn't already working this way (when one of my chocolatey packages stopped installing correctly but I didn't realize because the errors were buried in the middle of a giant script log and everything had proceeded in spite of the errors) was a rude surprise.

For the time being I'm going to take a fork of boxstarter with the changes in the PR, but it would be great if we could get some kind of option for continue or stop on failure in the official boxstarter releases.

Thanks!

[mwallner]

@simmdan - would an optional switch, such as the suggested -StopOnError be possible in your environment?
i.e. adding the switch to your Boxstarter calls that absolutely need to stop after the first error occured.
(otherwise I currently see no way that we can move forward with #296)

[simmdan]

Yes an optional switch would work fine in my environment.

[mwallner]

@simmdan I've finally had time to spend a little time on this, see GH-402 , anyway: I think that GH-401 may actually be a better fit for your use case once we've got some implementation for that issue.
(I've got similar use case where I want to install as many packages as possible, but get a meaningful result/state- if any package install failed - at the end of the Boxstarter invocation)

[pauby]

I like the idea of this ultimately reporting back to the user, after Boxstarter is finished, on how many packages were installed and how many were not (including errors if we have any). This is being discussed in #401