Support the Checks API

[Tom Manterfield]

The Checks API results follow a different structure to both the search APIs and the other GitHub APIs.

Where 'normal' GitHub APIs return their results in a list of objects:

[
  {},
  // and so on...
]

Search returns results in a dict with the objects under the items key (support for this was added in PR #68):

{
  "total_count": 1,
  "items": [
    {},
    // and so on...
  ]
}

Checks API however returns results in the same dict structure as above, but under a key that names the items:

{
  "total_count": 1,
  "check_runs": [
    {},
    // and so on...
  ]
}

The above means that the checks API does not work with getiter() as it has the same issue the Search API initially had, instead returning the keys as strings.

As you can see in abc.py

if isinstance(data, dict) and "items" in data:
            data = data["items"]

It only handles the specific key 'items' (since that was all that was needed for search).

I'm not sure if this issue impacts any of the other segments of the API.

[Jonathan Sick]

I've run into the same issue, but with the Apps API, e.g. GET /installation/repositories where the "items" key is "repositories":

{
  "total_count": 1,
  "repositories": [
    {},
  ]
}

Would a PR that adds an items_key: Optional[str] = None parameter to getiter be the way to solve this? Then users can specify items or repositories or check_runs or whatever the particular endpoint requires.

[Mariatta]

Would a PR that adds an items_key: Optional[str] = None parameter to getiter be the way to solve this?

I think adding the items_key parameter is a good solution. We can default it to "items" for backward compatibility.

[Brett Cannon]

It sounds like this inconsistency is enough of a problem to need to add the parameter, and I agree with @Mariatta on the items_key argument, but it should probably be keyword-only.

[Mariatta]

I've made the PR to address this. I added the iterable_key param to getiter.