Support for Review Requests endpoints?


#1

Is there support for the Review Requests endpoints for App bots? I don’t see them listed in either the Permissions or Available Endpoints sections of the docs.

My use case is that I have a bot that assigns code review of PRs to users based on various analyses it performs on the PR. Currently I’m handling that with Issue Assignees, but I would like to use Review Requests instead.


#2

@aergonaut No, those aren’t supported yet.

We’re in the midst of doing a full audit on the REST API endpoints to see exactly what we’re missing support for, and how long it will take to add that support. Once we’re through with an audit we’ll be able to give you an estimate of when those will be enabled.

We’ll report back here with that information when we have it.


#3

@kytrinyx I think that “create a PR review request” is still unsupported? i.e. https://developer.github.com/v3/pulls/review_requests/#create-a-review-request


#4

I found a mention of it here:

Request support for additional endpoints for Integrations

In it, it’s mentioned that it’s supported, but it never works for the endpoint I linked to above and my app always receives a 422 rejection. I also can’t locate it here: https://developer.github.com/v3/apps/available-endpoints/

My app provides the app header plus thor preview header: application/vnd.github.thor-preview+json.

Example rejection headers:

"date": "Wed, 13 Dec 2017 01:20:28 GMT",
"content-type": "application/json; charset=utf-8",
"content-length": "210",
"connection": "close",
"server": "GitHub.com",
"status": "422 Unprocessable Entity",
"x-ratelimit-limit": "6450",
"x-ratelimit-remaining": "6366",
"x-ratelimit-reset": "1513131202",
"x-github-media-type": "github.machine-man-preview; format=json, github.thor-preview; format=json",
"access-control-expose-headers": "ETag, Link, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval",
"access-control-allow-origin": "*",
"content-security-policy": "default-src 'none'",
"strict-transport-security": "max-age=31536000; includeSubdomains; preload",
"x-content-type-options": "nosniff",
"x-frame-options": "deny",
"x-xss-protection": "1; mode=block",
"x-runtime-rack": "0.065000",
"x-github-request-id": "88B4:266E1:130C460:16D5B7A:5A30805C"

#5

Thanks @rarkins I’ll take a look at what’s going on here.


#6

@kytrinyx FYI, I tried one more thing after my post just in case, but it also fails. To summarise:

  1. Using the thor-preview header and specifying a non-empty list of users plus an empty ([]) list for teams fails
  2. Leaving off the thor-preview header and specifying only the users array also fails

From what I could tell of the API, requested team requests is still in preview and needs the thor header, but requested user requests is now officially part of the API so should not. However I found that both approaches have failed, as per above.

I have logged and can provide you more x-github-request-id values if that helps.


#7

@rarkins I figured out what’s going on—I was confusing the branch protection endpoints that require pull request reviews and the endpoints that create a PR review request.

It does look like this one is next up to be enabled. I don’t want to promise a timeline (especially as I’m not the one doing the work), but this should be available shortly.


#8

@kytrinyx will there always be this gap and uncertainty between the regular API and the app API, or will it one day be automatically kept in feature parity? Seems pretty confusing for all involved right now.


#9

We’re working to close the gap. Once we’ve done so I expect it to remain closed.


#10

Hi @kytrinyx this one seemed to drop off the radar. I can confirm that adding reviewers to a PR still fails for apps. Can you check again for when it can be added? Seems like an innocuous endpoint to still be left out after all this time.


#11

Hi @kytrinyx, it seems like this endpoint was left out by accident in the first place, so I don’t understand the long time we’re needing to wait to get the problem fixed. It seems pretty likely that app users would want apps to be able to detect and assign reviewers based on preset rules.


#12

@jch it looks like you may be answering questions more recently. Can you push for this rather obvious “requested reviewers” endpoint to be enabled for Apps?


#13

@rarkins that is something on our roadmap and currently being worked on. We will have documentation for it soon.

edit When it’s released, we’ll announce it on our developer blog https://developer.github.com/changes/