- Restored binary compatibility. The draft API has changed in some
significant way when it became public, and the PR took the liberty to
delete removed constants and method signatures. I brought them back so
that older clients can keep functioning.
- Introduced a builder pattern to create PR review
- replying to a review comment should be an instance method, not a
static method.
- GHPullRequestReview and GHPullRequestReviewDraft was not making sense
to me, since GitHub API doesn't differentiate them. It creates a
practical problem of not being able to submit a review comment unless
you created the review comment in the same JVM session. That said, I
don't understand the point of this two phase approach in the GitHub
API to begin with!
this fixes parsing of response of WS call submitting a review to fail
when event of new review is REQUEST_CHANGES
also, specifying event when creating a pending PR review is useless and
providing it when submitting the review is enough
I think what's going on is that GitHub takes some non-zero amount of time to compute this value, and our test runs too fast sometimes and try to fetch a PR before its mergeability is computed
Setting labels and assignee on Pull requests failed silently, because
the API endpoint being hit contained '/pulls/' rather than '/issues/'.
"Every pull request is an issue, but not every issue is a pull request.
For this reason, “shared” actions for both features, like manipulating
assignees, labels and milestones, are provided within the Issues API."
https://developer.github.com/v3/pulls/#labels-assignees-and-milestones
If the test assertion fails, we want the pull-request to be closed anyway.
You can't have more than one pull-request merging a given branch into
another, so leaving the PR hanging will cause subsequent test runs to fail
in setup.
