Introduce before and after steps for a task.

[jenpet]

Hey guys, I fiddled around with some before and after 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.

[jenpet]

@yields ping 😊

[yields]

LGTM, seems like it just needs some docs to match the rest of the codebase.

[jenpet]

No problem, will do so. Just wanted to make sure that you guys are ok with the feature(s).

[jenpet]

@yields updated the code documentation and the readme accordingly. If you are happy with it, I will squash the commits into a single reasonable commit.

[yields]

Awesome! -- thanks for the extra docs :)

[CGamesPlay]

Hi guys, I just submitted #58 and was looking over this code. I just wanted to provide this commentary because the feature isn't technically released yet and there's no better time to fix it than before it's broken!

1. The example documentation suggests using exec: git pull -r as a before subtask, which would prevent all of the following commands from running, because robo wouldn't be running after that happened. Also, the main task in the example is an exec, which also means that the after subtask couldn't possibly run, either. So, this feature is effectively incompatible with exec tasks.
2. The ability to define these before and after commands on a single task does not make sense to me, because for both script and command tasks, you could trivially have put that code into the actual task. This means that the only viable use-case for this feature is to define before/after subtasks on the entire robo.yml file.
3. The only allowed error handling mode is "report but continue". This frankly seems like the least-useful default mode to use, as I can't imagine a use-case where I want to run my main task if my setup code fails. Similarly, running my after task after my main task fails feels like it actually makes troubleshooting more difficult, not less.

Now, what does this feature give users of robo? Remember that per-task before/after functionality is trivial to move into the main task. The global before-after tasks could be moved into an external wrapper script, but then you lose the ability to interpolate variables in them, which was presumably a motivating factor for this feature. Fortunately, it's very simple to accomplish this using robo's pre-existing composition feature. I've included a rewritten version of this below. Note that the UX is different, we have to run robo wrap foo instead of robo foo. However, this could be accomplished using an alias or shell script to even avoid this problem. The advantage of this wrapper is that the user gets to define their own error handling. Adding set -e to any of the commands means that you get "report and fail" error handling semantics. Other combinations are available too, because it's just a shell script (e.g. "report but continue" on before task and "report and fail" on main task).

I don't mean to come in and poo-poo @jenpet's hard work, so I'm sorry that all I have to offer right now is negative feedback. But I think that this feature adds substantial complexity to robo that wasn't fully considered with the feature was added.

foo:
  command: |
    echo "local before {{ .foo }}"
    git status
    echo "local after"

wrap:
  command: |
    echo "global before {{ .foo }}"
    robo "$@"
    /global/after-script.sh

variables:
  foo: bar