Use Github APIs to sync state instead of webhooks

[rcullito]

This is meant to generally address a certain class of issue around discrepancies between github state and the local SOB state – which is currently linked via webhooks listening for manually generated user actions taken on Github's UI.

The goal here would be to replace the need for taking a defined series of manual steps with a central function such as refresh-state

examples of specific issues this should help address include:

• Updating info on GitHub(issue title, GitHub profile name) doesn't affect SOB #414
• Editing PR (revoking issue reference) doesn't remove open claim on SOB #416
• Reopened PR is not displayed as open claim on SOB #417
• PR created before putting bounty label is not recognizable as open claim #423
• PRs with keywords in commit messages are not recognizable by SOB as claims #362

[martinklepsch]

To expand on this: the issues @rcullito linked are all caused by our DB state getting out of sync with the "source of truth" (which is GitHub). Our current approach derives state from a set of webhook payloads. This is troubling for two reasons:

• Missing a single webhook will cause our database to get out of sync with no way of catching up
• We need to perfectly handle each webhook event from edits to label changes

An alternative approach to doing this kind of event sourcing on webhook payloads might be utilizing GitHub's API to derive the state that should be in our database. This could still be triggered by incoming webhooks but would allow us to elegantly avoid the two problems outlined above.

In case of trouble, we could also easily initiate this process from the REPL or via an API.

[vitvly]

Some time ago when we had to re-check our data against Github state we used a small fn:

open-bounty/src/clj/commiteth/github/core.clj

Line 367 in a70696f

(defn get-labeled-issues-for-repos [repos auth-params]

. It uses GitHub API search. Hopefully we can use it for the purposes of copying the GitHub state, for issues at least. Need to recall better how to find PRs, because we don't put a label on PRs, so maybe there's another way.

[martinklepsch]

I think the (refresh-state issue-id) function would take the issue-id as an argument, PR links could then be extracted from text or references not sure what GitHub's API provides for that.
Everytime we get a webhook that references an issue (could be issue or PR events) we call refresh-state for that issue. Or so 🙂

[vitvly]

We'd still need to search for issues with a bounty label because it might happen that we don't have an issue in our db, so no issue-id to pass to refresh-state.

[martinklepsch]

I reached out to GitHub support to understand how we could use their API to identify PRs that are claims towards a bounty/issue. While it's not directly possible to retrieve the PR that closed an issue the (beta) timeline API allows finding all PRs that referenced an issue. Parsing the body and title as we do now should then allow us to identify claims quite easily:

curl -H 'Accept: application/vnd.github.mockingbird-preview' \
  https://api.github.com/repos/TestingEnvENV/TestEnvAtt5/issues/186/timeline

https://developer.github.com/changes/2016-05-23-timeline-preview-api/