RFC: notification resources

[vito]

Rendered

Related to, but not dependent on #24.

[kallisti5]

Feedback? One thing we really miss from buildbot is "State change only" notifications.
Example:

• Success
• Success
• Success
• Error!
• Error!
• Success

Instead of 6 notifications, having the option of only 2 would be a lot better from a "preventing spam" standpoint. We rolled our own custom notification plugin, and still wasn't able to accomplish it. (no persistent data between notification plugin runs)

[vito]

@kallisti5 Good call! I've listed that under 'Motivation' so I don't forget. 👍

[agonbina]

Maybe this is already addressed in the specification, but would also be interesting to version notifications so that you can update them to avoid too much spam (ex. a slack notification to notify build started, can then be updated to "failed/succeeded") etc.

[Anonymous-Coward]

I was led here from here.

Noob question: why not replace a dedicated notifications resource with a dedicated events resource, with events being able to trigger arbitrary tasks/jobs? Would increase the flexibility and power of concourse overall, and bring it closer to its stated purpose of being an automation tool.

The current approach, of triggering jobs only on get of resources is often not that convenient. Events, OTOH, are quite flexible.

[kallisti5]

I think "onFailure" does exist for notifications now? ... so this one might be a little less relevant than it once was. State change only events would be a nice feature though.

[Anonymous-Coward]

I think "onFailure" does exist for notifications now? ... so this one might be a little less relevant than it once was. State change only events would be a nice feature though.

I was thinking of more generic events - maybe arbitrary identifiers you can attach to success, failure and finally - just like exception handling. Then, specify the event as a trigger for another job in the same pipeline.

[taylorsilva]

Not doing this anymore.