Mystery - Sending to multiple channels

[ghostsquad]

I've read the code, and it looks like to enable multiple channels, you loop through a channel list. What I don't understand is how this is even possible. According to the documentation here: https://api.slack.com/incoming-webhooks

You cannot override the default channel (chosen by the user who installed your app), username, or icon when you're using Incoming Webhooks to post messages. Instead, these values will always inherit from the associated Slack app configuration.

Can someone clarify this?

[jhunt]

You might want to check the git blame on those line; APIs have a tendency to change (and become more secure / less flexible) as time marches on.

[dennisjbell]

Confirmed -- most of the optional parameters on out are no longer supported by the Slack API, such as changing the channel, username or icon. The only way to support this now is to use multiple slack-notification-resources, each using different webhook urls.

[ghostsquad]

Ya, I see that multiple channels still works if you use the legacy incoming webhooks slack app.

That's why I was confused. Thanks for helping to confirm my suspicions!

[ghostsquad]

It might be worth deprecating multiple channel functionality so that when Slack finally pulls the plug on this legacy usage, it's easier to conform.

[jhunt]

Not to tease, but we've got a better idea in the works :)

[ghostsquad]

@jhunt SWEET. I've been working on something to replace this resource anyway. https://github.com/ghostsquad/slack-off/tree/develop

Can you point me to V.Next so I can see what's in the works? Maybe my take on this resource isn't necessary.

[jhunt]

Don't tell anyone, it'll be our little secret.

It's called Shout! (https://github.com/jhunt/shout)

It's deployable via BOSH (https://github.com/jhunt/shout-boshrelease)

It has a Concourse resource! (https://github.com/jhunt/shout-resource)

[ghostsquad]

Interesting. Though, it seems unnecessary to run an external service for this. Not sure what the benefits are of that, besides being an able to notify only when things go from good to bad or vice versa. With external state, you could very easily do the same thing within the resource itself.

[jhunt]

Goals are many:

1. Get rid of ${system_of_the_day}-resource explosion (we have slack, email, flowdock, hipchat, stride, and counting...)
2. Provide notifications for more than just concourse (lightweight monitoring for other things, like SHIELD)
3. Business logic that ought not go in the pipelines will stay in the external service. Things like time-of-day dispatch (email me after hours, slack me during the day) and escalation (the pipeline is STILL broke, yo) - these generally cut across pipelines, and as someone who manages dozens (if not hundreds) of pipelines, I really don't want to spend my days cutting new YAML configs to make concourse do my bidding on the notification front.

As for increased infra costs, we're probably going to be colocating the notifications on the same node as TSA/ATC/DB in our Concourse deployments so it's just a nominal usage increase.

[ghostsquad]

Cool. That actually does sound quite nice.

[drnic]

Indeed it does sound good.

---

From: Wes McNamee notifications@github.com Sent: Saturday, August 11, 2018 4:52 am To: cloudfoundry-community/slack-notification-resource Cc: Subscribed Subject: Re: [cloudfoundry-community/slack-notification-resource] Mystery - Sending to multiple channels (#58)

Cool. That actually does sound quite nice.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/cloudfoundry-community/slack-notification-resource/issues/58#issuecomment-412141726, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAAAbH7_ILG0BypK_RC4suMn_udgNp3Vks5uPbpjgaJpZM4VvavN.