Exit early on patch failure if bloom is being run non-interactively.

[nuclearsandwich]

If git-bloom-release is run non-interactively then that should be
propagated to the actions command so that actions are not blocked on
interactivity.

This patch uses an environment variable to send that message since the action commands do not have a --non-interactive flag and their command-line arguments are all defined statically in the tracks file so using the environment makes more sense than further munging those tracks unless we consider adding a {non-interactive} template to the tracks string, which would require updating all outstanding tracks files, also not my favorite idea.

I haven't audited the code for additional interactive points inside tracks files and I'm not yet sure if I mean to or if I plan to play "whack-a-mole" with them as I find them naturally over time.

[cottsay]

This patch uses an environment variable to send that message since the action commands do not have a --non-interactive flag and their command-line arguments are all defined statically in the tracks file so using the environment makes more sense than further munging those tracks unless we consider adding a {non-interactive} template to the tracks string, which would require updating all outstanding tracks files, also not my favorite idea.

This is tricky. Some action list entries take -y, but not all. We're in a strange state with non-interactive as a whole, though, because the existing default action list is passing -y but we're not respecting that during patching, obviously. So -y has a different meaning when passed to an action than it does when passed to git-bloom-release at the top, where it seems to mean "I'm running in a script so don't ask for input".

Maybe a better approach to running in a script would be to just close stdin and make sure the prompts can handle it. I don't know. It sounds like a non-zero amount of work.

tl;dr - this change doesn't make the madness all that much worse, but I'm still not thrilled about it. If it's needed to unblock progress, then I think it's OK to merge.

[nuclearsandwich]

Maybe a better approach to running in a script would be to just close stdin and make sure the prompts can handle it. I don't know. It sounds like a non-zero amount of work.

I gave this a shot by setting stdin=subprocess.DEVNULL in the subprocess call for git bloom-release was enough to break the interactivity but it also causes bloom to assume the patch imports successfully so I think some work is going to be required still to make it "fail" on no input.

[cottsay]

I like this SO much better. We should change the rosdep rule failure to do the same thing. That way, -y only suppresses non-failure interactivity. To automatically fail the command instantly, you close stdin.

Another time perhaps.