rubygems/rubygems.org — Issue #366: Webhooks for yanked gems
Author: laserlemon
Created: 2011-11-21 12:26:59+00:00
State: open
Labels: feature

Yanking gems is a necessary evil.

I don't think there's any good way to prevent authors from prematurely pushing broken or unfinished gems. Unfortunately, yanked gems often leave people's projects in gem dependency limbo. For instance, the good people of @collectiveidea have found their projects depending upon the `gherkin` gem (indirectly through `cucumber`) and the surrounding dependencies are such that `gherkin` is locked down to `~> 2.3.8`. The problem is that the only versions that satisfy that requirement are `2.3.8`, `2.3.9` and `2.3.10`, all of which have been yanked.

http://rubygems.org/gems/gherkin/versions

While scenarios like the one above can't always be avoided, I think it's important to notify developers when a version is yanked so they can take appropriate actions and that web hooks are a great way to deliver those notifications.

In my mind, the easiest way to pull it off was to hit the same registered web hook URLs rather than registering separate hooks for yanks. So if we were to hit the same URLs, either the method or the payload would have to change in order to differentiate pushes and yanks. I was in favor of an identical DELETE request until I started getting mixed signals on whether DELETE requests can/should have request bodies.

If we were to change the web hook payload, I think the existing webhook bodies should stay the same and the new hooks should take on a backwards-incompatible form so that yanked gem versions aren't mistaken for newly pushed gem versions with existing web hook subscribers.

What are your feelings on the concept of yank web hooks and their implementation?