6 ms·
Upcoming Changes to GitHub Services
- johns 14y agoAt 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 14y agoDoesn'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 14y agoYou 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 14y agoWell, that's what the post-receive URLs (https://help.github.com/articles/post-receive-hooks https://help.github.com/articles/post-receive-hooks) are intended for, though you're right that you won't appear in the services list.
- deleted 14y ago[deleted]
- i386 14y agoThere is a service hook for our product. Does this mean its broken as of today?
- technoweenie 14y agoNope. If you were trying to submit it tomorrow, it'd be rejected though.
- i386 14y agoThanks for the clarification. If you work for Github it would be useful if the blog clearly stated it (maybe I just missed it?)
- dangrossman 14y ago> 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).