Re: Feature Proposal: Event Hooks

[Tristan Maat <tristan maat codethink co uk>]

Hi,

I went ahead and implemented a proof of concept for this, using
Jonathan's suggested configuration format - the branch can be found
here: https://gitlab.com/BuildStream/buildstream/tree/event-hooks.

The proof of concept currently allows specifying three hooks:
``track-fail``, ``track-start`` and ``track-complete``, which trigger
exclusively on those events for the ``bst track`` command. This can be
tested using the following ``~/.config/buildstream.conf``:

    hooks:
      - cause: track-start
        commands:
          - "read -r context; notify-send \"bst\" \"Tracking started: 
$context\""
      - cause: track-complete
        commands:
          - "read -r context; notify-send \"bst\" \"Tracking complete: 
$context\""
      - cause: track-fail
        commands:
          - "read -r context; notify-send \"bst\" \"Tracking failed: 
$context\""

The remaining question is - what hooks should buildstream define?

I suggest having a ``start``, ``complete`` and ``fail`` hook for each
of the following commands, as well as overall hooks for those
keywords:

  - push
  - pull
  - track
  - build
  - fetch

I don't believe there are any other events that would be useful to
expose, since the other commands do not take quite as long to execute,
and seem like they would not be particularly important on build
servers.

My main concern is that this may be too much - for my own purposes,
``start``, ``complete`` and ``fail`` are more than enough, and it will
be harder to remove hooks later than to add them.

Please do share your thoughts on this :)

Thanks,

Tristan Maat


On 13/11/17 13:39, Jonathan Maw wrote:
> 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
> _______________________________________________
> Buildstream-list mailing list
> Buildstream-list gnome org
> https://mail.gnome.org/mailman/listinfo/buildstream-list