Re: [BuildStream] Breaking change: changing '--force or fail' to y/n prompts

[Angelos Evripiotis <angelos evripiotis gmail com>]

(in reply to my original mail)

Unfortunately no-one won the prize for spotting the deliberate mistake.

The answer was of course that we will also move scheduler.on-error to
be prompt.on-job-error in buildstream.conf for consistency.

The rename would avoid confusion with the scope of the errors it is
controlling.

It would also change from this:

# What to do when an element fails, if not running in
# interactive mode:
#
# continue - Continue queueing jobs as much as possible
# quit - Exit after all ongoing jobs complete
# terminate - Terminate any ongoing jobs and exit
#
on-error: quit

To this magnificent beast (except with better whitespace):

# What to do when a pipeline job fails. In all cases the program will exit
# with an error code; unless retries actually succeed:
#
# continue - Continue queueing jobs as much as possible
# finish - Finish ongoing jobs, don't start new ones
# terminate - Terminate any ongoing jobs and exit
# ask-continue - Ask, default to continue, assume this if non-interactive
# ask-finish - Ask, default to finish, assume this if non-interactive
# ask - Ask, default to terminate, assume this if non-interactive
#
on-job-fail: ask-finish

It would gain some additional options, since the scope would change from
'if non-interactive' to 'always', for consistency with the other prompt
options.

While I'm there, 'quit' would be renamed to 'finish', which seems like a minor
clarification. It seems more distinct than the 'quit/terminate' combo.

I'd also change the default to 'ask-finish', which would behave the same
way as the old 'quit'.

The command-line option '--on-error' would change in the same way to
'--on-job-fail' and gain the new options.

I need to check what the current exit code behaviour is on failed builds,
hopefully this wouldn't be a change.

Again, I'd prefer not to do any of this, and instead remove the prompt
namespace completely, along with the 'are you sure?' prompts. I'm merely
following my understanding of the design philosophy. Please say if you also
prefer not to do this :)

Excitingly, with build trees this would open the possibility to configure bst
to 'continue' and then have a useful message at the end for how you might shell
into the failed builds, e.g. something like:

$ bst build app.bst
...
Some elements failed to build, you can shell into those with:

    bst shell --build-tree failed1.bst
    bst shell --build-tree failed2.bst

$ echo $?
.. some error code ..

That would be behaviour I'd actually mildly prefer for some projects I'd be
building. I'd probably be happy to supply the existing '--on-error continue'
though and reap the same benefit.

Cheers,
Angelos