

Upcoming Changes to GitHub Services - bencevans
https://github.com/blog/1402-upcoming-changes-to-github-services

======
i386
There is a service hook for our product. Does this mean its broken as of
today?

~~~
technoweenie
Nope. If you were trying to submit it tomorrow, it'd be rejected though.

~~~
i386
Thanks for the clarification. If you work for Github it would be useful if the
blog clearly stated it (maybe I just missed it?)

~~~
dangrossman
> For an example of a service that won't be accepted _after today_ , check out
> Campfire. It uses other Ruby gems and contains custom logic to transform the
> GitHub payload to Campfire messages. _Existing hooks will keep working_
> (don't worry 37signals, we Campfire).

------
johns
At this point aren't they big enough to shift the onus onto the service
providers to create hook endpoints that all accept the same payload? I don't
see any reason why the service hooks section needs to be anything more than a
list of URLs you want hit. You could still list all the providers and just
automatically create proper URLs for each service. No need for the Ruby layer.
IFTTT and Zapier and the like can fill in the rest for those that don't want
to create the webhook interfaces.

~~~
thedaniel
Doesn't this cover shifting the onus onto service providers?

"As of today, all new services must accept an unmodified payload over HTTP.
Any service that does not will be rejected."

~~~
johns
You still have to write the Ruby layer if you want to appear in the list. I
think they should get rid of the Ruby file requirement.

~~~
thedaniel
Well, that's what the post-receive URLs
(<https://help.github.com/articles/post-receive-hooks>) are intended for,
though you're right that you won't appear in the services list.

