Open tortillaj opened 7 years ago
This raises some interesting questions. I was making this service pretty smart - it evaluates the build object and decides what the notifications should look like and to whom they should be sent. This proposal would, I suppose, make it dumb and move that logic to wherever these events are being originated (or some intermediary in some cases?).
I'll need to give this some thought. +1 to adding a carrier pigeon plugin though - for sure - carrier pigeons are awesome. Maybe we can use PigeonGram.
@tizzo @lliss (and anyone else!) -
Currently, this service is reading off the specific,
build_events
channel. When a new build event is received, the type of desired notification is read off its configuration (which is received from the.probo.yml
).I'm floating the idea of altering this service so that it listens to an abstract,
notifications
event channel. An individual event on this channel might look something like this:Each type of notification is already planned to be a separate plugin, within this service. Also, each of these types will need their own settings. For example, to flesh out the webhook example:
Basically, this service is simply a delivery system for notifications. It is provided any and all parameters in their finalized form. (Notice the
message
property above already has the build id and link)That said, each plugin will have its own requirements for how a notification is formatted. For example, Slack will need its data posted in a specific format, and email notifications will have some HTML template that contains the passed parameters. This plugin specific processing happens in this library.
Benefits of this change