robo

This resolves #55. My notes on the implementation: 1. I had to do it in the Task section because the signal mask is inherited by the child processes, so ignoring SIGINT there actually causes the children to ignore it too. I don't see anything in the exec package that would allow not inheriting the signal mask, so we start the process, then mask the signal while we wait for the process to finish. It may be possible for the task to start and ignore SIGINT, and then for an external process to SIGINT the process group, both before our call to signal.Ignore, which would mean that the bug still exists. This feels extremely unlikely. 2. I only handled SIGINT. I don't think any other signals are typically delivered to an entire process group, so I think this is OK.

(Sorry, I couldn't resist that issue name.) Hi, I'm a big fan of robo, and I've been using it increasingly over the past year or so. I've recently noticed that robo will return control to the shell immediately when it receives a SIGINT. This is a problem, because child processes of robo may still be running cleanup behavior. The upshot of this is that any program which has cleanup behavior on exit will still be running in the background, and if it produces any output (or changes terminal modes), it will be printed in the middle of the user's shell prompt. For a quick demo showing this behavior, see this gist. I added a Makefile to compare the behavior against make, which I would argue is the correct behavior: it catches the signal, stops running new commands, waits for all child processes to exit, and only then exits itself. In order to bring robo inline with make, I think Robo just needs to ignore the relevant signals. The child processes are already delivered the signal as well, so the call will terminate naturally. I think the proper signals to catch are SIGINT and SIGTERM. There's a stylistic question about where this behavior should live. My suggestion is , since it's a global effect, and putting it in feels like a violation of the encapsulation. Would a PR implementing this behavior be accepted?

Hey guys, I fiddled around with some and functionality I could use within robo. Hopefully this finds a way into master. Let me know what you think, will update the docs after we're all happy with it :-) A task is now able to have several steps which are executed before and after its own execution. The config syntax for this is the same as for the task itself: 'command', 'script' and 'exec' are supported. A task and all of the preceeding steps will still be executed even when the before steps are failing. Running a task now returns a list of errors which are logged according to their occurrence for easier troubleshooting.