add in handling for PR milestoned/demilestoned events

[urkle]

Github sends down the milestoned/unmilestoned (setting/unsetting the milestone) events as issue events even for pull requests. Thus they do not get mapped correctly to be processed as a PR change in Peril

[urkle]

@orta so the issue with my approach here is that the payload from github on the event does not contain the ".head" node. This would be the same issue I'll run into for issue #342 as well. Is there a means to do a "blind" trigger of a PR in peril?

[orta]

Hey Urkle, I'm a little wary of this PR - it disconnects peril's behavior from the GitHub docs, which is something I've been really trying not to do. Mainly that only the PR events get the Danger PR DSL, and everything else is just the event json

So, I'd rather not accept it, though the node version definitely make sense - I default to 8 personally so I always forget to switch. I can extract that commit and merge it into master?

[urkle]

@orta the issue is.. the milestoned event can be a pull request. they just incorrectly send it always as a "issues" event. (I have reported this to them but they have not responded back and I doubt they'll fix it). Maybe as some pre-processor that translates the specific "bad" events?

so the problem I'm having is that I need these milestoned/demilestoned events to trigger processing on my pull requests.

I can extract the node 8 out to a separate PR.

So I'm open to suggestions on how I can teach Peril to handle this in a clean way. Right now the main issue is we have to perform some "other event" on the PR to get peril to run again (e.g. change a label, or add a comments) because it won't run for the bad milestoned events from GitHub.