Slack Build Notifier plugin

[Ashwanth Kumar]

Plugin that pushes build notifications to Slack channels via webhooks. 

Built and tested it on Mac. Haven't tested it on a Windows / Linux setup, no reason why it shouldn't work on these. 

Features

- Can send notifications to a channel / user

- Configure which pipeline / stage combination needs notifications

- Ability to provide different channels for each pipeline

Ref - https://github.com/ashwanthkumar/gocd-slack-build-notifier

--

Ashwanth Kumar / ashwanthkumar.in

[srinivas upadhya]

Cool! FYI, ThoughtWorks is running a plugin competition. You can register & compete with this plugin if you wish to.

If you are, All the best! :)

[Ashwanth Kumar]

Thanks! I sent a PR last night :-) 

I've couple of feature request on the notification plugin endpoint.

1. Can we expose pipeline group information as part of the response? 
   
2. For notification plugins of this nature, it would be helpful if we can have access to the existing Notification Filters already built into GoCD. For people with already huge set of filters it would be (a little) painful to migrate. 
   

On Mon, Feb 2, 2015 at 11:28 AM, srinivas upadhya <srinivas...@gmail.com> wrote:

Cool! FYI, ThoughtWorks is running a plugin competition. You can register & compete with this plugin if you wish to.

If you are, All the best! :)

[srinivas upadhya]

On Monday, February 2, 2015 at 3:20:11 PM UTC+5:30, Ashwanth Kumar wrote:

Thanks! I sent a PR last night :-) 

Saw that. Hope you have registered here.

I've couple of feature request on the notification plugin endpoint.

1. Can we expose pipeline group information as part of the response? 
   

This information is not available in database object here. I do not want to do a config search, since I am not sure how much of a performance hit that would be. I will see I can do something about this.

1. For notification plugins of this nature, it would be helpful if we can have access to the existing Notification Filters already built into GoCD. For people with already huge set of filters it would be (a little) painful to migrate. 
   

I want to make the pipeline material related, stage history related & user related information available using this. With this, plugins will be able to query data, but this will require some work.

1. Feedback - The `stage-result` in the response comes as "Failed" (when a stage fails) irrespective of the number of consecutive failures. Is it possible to return the existing convention of "Failed" / "Broken" / "Fixed" / "Passed"?

 Again, this information isn't available directly in database. Which means I will need to add database queries to compute this, which I am not very keen (for performance concerns). Hopefully by doing the above you will be able to do the computation on the plugin side.

[Ashwanth Kumar]

Ah, thanks for pointing out. "Register for updates" was kinda misleading, I thought it was some mailing list registration form. 

ApplicationAccessor would be good start. 

Thanks for the update.