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 → i386]

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

[i386 → technoweenie]

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 → i386]

> 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 → johns]

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 → thedaniel]

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 → johns]

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.