Re: Feature Proposal: Event Hooks

[Jonathan Maw <jonathan maw codethink co uk>]

On 2017-11-13 13:05, Tristan Maat wrote:
> Hi,
[snip]
> I can see it being slightly problematic that these events would just
> trigger on all projects and elements, so there should probably also be
> events that trigger on specific elements and projects. E.g., for the
> 'pony.bst' element in the 'ponies' project:
>
>     hooks:
>       - on-error-ponies:
>         - commands:
>           - /usr/bin/notify-send 'Oh no! One of the ponies broke!'
>       - build-finished-ponies:pony.bst:
>         - commands:
>           - /usr/bin/notify-send 'Your pony is done!'
>
> A serious proposal for plugin-defined hooks is probably out of scope
> for now, however, if there is enough interest in this, element and
> source plugins could specify their own hooks, allowing fun things like
> this:
>
>     hooks:
>       - git-pre-commit-ponies:pony.bst:
>         - commands:
>           - /usr/bin/notify-send 'We probably never even run a git
> pre-commit hook with BuildStream'

Hi Tristan,

I think embedding information in the hook's name that needs to be 
unpacked might be a bit more complicated than it needs to be.
My counter-suggestion is:

    hooks:
    - cause: on-error
      project: ponies # if field left blank, applies to all projects
      element: pony.bst # if field left blank, applies to all elements
      commands:
      - /usr/local/bin/speech-synth "The user of this computer is a 
foolish fool!"

This ought to let us reuse python's yaml parsing to get the necessary 
information, rather than needing to extract the data from the string, 
ourselves.

Cheers,

Jonathan