I would like to know if there is an function in the Github API which would return the status of a pull request whether its accepted or rejected. Does such a function exist?
I would like to know if there is an function in the Github API which would return the status of a pull request whether its accepted or rejected. Does such a function exist?
I was stymied by this problem, too. I had a hard time finding relevant info in the docs.
Option A
The tactic I've landed on is to use the issues search endpoint with the review qualifier in the q param.
So, in my case, when I want to see all PRs assigned to me that have not yet been reviewed, I'd hit this endpoint: https://github.com/api/v3/search/issues?q=is:open+is:pr+review-requested:jordan-bonitatis+review:none
Other review qualifiers include approved and changes_requested as explained here: https://docs.github.com/en/github/searching-for-information-on-github/searching-issues-and-pull-requests#search-by-pull-request-review-status-and-reviewer
Option B
If you want to see the review status for a given PR, instead of getting a list filtered by status like in my example above, you can hit the pull requests reviews endpoint: /repos/:owner/:repo/pulls/:number/reviews
This will return a list of reviews for the PR, each of which have a state key.
Note that a given PR may have multiple reviews with conflicting states. Like, if teamMemberA approved it but teamMemberB requested changes. You'll have to traverse the entire list and decide how you want to treat it based on all the states.
I had a similar requirement - to know if a PR has been approved or not before merging it to master. I added a rule on the repo to ensure that every PR must be approved prior to merging. Then on using the API to get details about the branch there was one field which stated if the branch was clean to merge or blocked . I used this as a way to mange things in my app.
mergeable_state
This is now possible using GraphQL.
Specifically if the mergeStateStatus enum is BLOCKED then the pull request hasn't been approved and for any other status it would have been approved.
This enum is present in the PullRequest object. Do note that at the time of posting this is a preview feature and so must have the appropriate header to work. It will also not work using the GraphQL Explorer while it's in preview.
Depending on the repo configuration you can get the answer one way or another. The examples below use the GraphQL API.
You can query reviewDecision on the pullRequest field for a given repository.
reviewDecision is of type PullRequestReviewDecision, an enum with values of APPROVED, CHANGES_REQUESTED, and REVIEW_REQUIRED.
Example query:
{
repository(name: "gatsby", owner: "gatsbyjs") {
pullRequest(number: 30371) {
title
reviewDecision
url
}
}
}
Response:
{
"data": {
"repository": {
"pullRequest": {
"title": "chore(gatsby): don't terminate dev server if graphql wasn't imported from gatsby",
"reviewDecision": "APPROVED",
"url": "https://github.com/gatsbyjs/gatsby/pull/30371"
}
}
}
}
If the repository settings don't specify that reviews are required, reviewDecision will be null regardless of approvals.
In this case you could iterate over the reviews and check the states. state is of type PullRequestReviewState, an enum with values of APPROVED, CHANGES_REQUESTED, COMMENTED, DISMISSED, and PENDING.
Example query:
{
repository(name: "create-react-app", owner: "facebook") {
pullRequest(number: 10003) {
title
reviewDecision
url
reviews(first: 100) {
nodes {
state
author {
login
}
}
}
}
}
}
Response:
{
"data": {
"repository": {
"pullRequest": {
"title": "Update postcss packages",
"reviewDecision": null,
"url": "https://github.com/facebook/create-react-app/pull/10003",
"reviews": {
"nodes": [
{
"state": "APPROVED",
"author": {
"login": "jasonwilliams"
}
}
]
}
}
}
}
}
It's possible to filter reviews for approvals: reviews(first: 100, states: APPROVED).
Note that two reviews will be returned if a reviewer gives his approval and subsequently requests changes.
Checking the PR state (of type PullRequestState) could be misleading: an admin user may have bypassed the required review process to merge changes.