Add support for the Checks API

[serkankirbas]

The Github v3 API now supports a first-class notion of check runs and check suites. Rather than binary pass/fail build statuses, integrations can report rich statuses, annotate lines of code with detailed information, and kick off reruns.

Github checks are becoming the de facto approach for implementing bots and for users who want to develop custom checks. I think supporting Checks API should be a high priority.

[bitwiseman]

Agreed. Those would be great! Do you have time to submit a PR?

[XiongKezhi]

Does the work to represent the Check Suite event payload still need any help? I am trying to implement the Checks API as a Jenkins plugin for a GSoC idea (see GitHub Checks API for Jenkins Plugins ), and I'm happy to help with this, so it can make my later implementations easier!

[bitwiseman]

It looks like we have read access to checks runs and checkrun events, but not suites and write access.

https://github.com/github-api/github-api/search?q=GHCheckRun&unscoped_q=GHCheckRun

You'll want to look at the links in the description and implement those. I'd suggest starting off with some smaller PRs or open a draft PR so I can give you pointers as you go along.

Also https://github.com/github-api/github-api/blob/master/src/main/java/org/kohsuke/github/example/dataobject/ReadOnlyObjects.java has some examples of how Jackson works.

[XiongKezhi]

Thanks, the links are really helpful, I was strange about those class without setters before. I'll start off with a draft PR on CheckSuite and CheckSuiteEvent.

[bitwiseman]

Partially fixed by #723 . CheckSuite and events are now present. Still to do are some CRUD methods such as https://developer.github.com/v3/checks/suites/#create-a-check-suite .
@XiongKezhi do you have time to do those as well?

[XiongKezhi]

Sorry, I just saw this message. Also, until I saw those builders and #724, I thought our project left other creating works to the users themselves because we have already provided a pluggable Http client. I wonder whether our current ways to implement those CRUD methods are to follow the design of #724? Like for creating a GHCommit, we use a GHCommitBuilder, so we also need a GHCheckRunBuilder or GHCheckSuiteBuilder to create them?

[bitwiseman]

@XiongKezhi
Sorry, for slow response - I've been on vacation the past week.

#724 is not yet merged. I've heard positive feedback so far, but it isn't quite ready for wide use - it needs to be tried with a more complex case than GHLabel.

But, yes, you probably want to create builder and updater classes.

[bitwiseman]

Now that we can create Check Runs, I'm going to close this issue. Further updates can be handled by issues and PRs.