Turns out I do care about formatting a little. We have a lot of builders and chained methods.
I think it is easier to follow long chains when lined up veritcally.
This may be controversial but it we're doing it. Having code formatting needs to be consistent
and a non-issue during code review. I'm willing modify the configuration if people see a strong
need, but formatting needs to be present and enforced.
- 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
