Add GitHub pull request

[joshsmith]

What's in this PR?

LOC looks scary but 2,075 of those are just JSON fixtures.

Adds:

• GithubPullRequest
• Event handler, pull request linker and user linker, adapter, validator, changeset builder
• Factory
• Tests

This also adds a GithubPullRequest belongs_to to Task as our way of identifying whether a given Task is an issue or a pull request. There should never be a case where a Task has both.

References

Fixes #1073

[joshsmith]

@begedin this was an awful lot of copypasta. I don't know how much of this deserves to be extracted out into similar places, but there does appear to be a fair amount of DRYing that could be done. Low priority, but perhaps we should loop back later to identify opportunities to clean this up?

[begedin]

I agree there should be plenty of things to dry up.

The various Linkers/Syncers, etc. act quite similarly across all events, so could maybe be moved into "Common"

[begedin]

Generally looks good, except we need a body parser. I'll start work on that.

[begedin]

This doesn't deal with the key part we need here - the parsing of the PR body to inferr which tasks are to be linked.

Really, it's the core logic of that that we need to work out, I think.

• parse body for closing keywords, extract github ids
• if they exist, find github issues with those ids, associate with tasks belonging to those issues, dissasociate form tasks belonging to other github issues
• if none are found, disassociate from associated tasks which do belong to github issues

The special case is when we get a pr created which does not close any issues. In that case, my suggestion is we

• create a codecorps task, which is linked to the pr, but not to a github iusse
• we leave that task associated from now on, regardless of new associations being added/removed

My philosophy is, that one was created on CC and can potentially hold information that will be lost, if we disassociate. Maybe at some point in the future, we allow "converting the PR to a github issue", which would associate that task with a github issue as well. At that point, it can behave like a normal task, but until that point, we shouldn't assume and try to avoid any automatons with it. If the PR has been linked to an issue since, let the user close the original task we've created if they want to.

[begedin]

@joshsmith I added a body parser with the function we need. Howe we want to hook it in is not quite clear yet, so I didn't to approach that on my own. I did write up my suggestion above, though.

[joshsmith]

Just a comment that it’s:

if they exist, find github issues and pull requests with those ids,