Feature request: review requests on user

schema-request

#1

Hi, I’m developing a slack bot to help my team have a summary of their pending/dismissed review requests across projects.

When using the reviewRequests node under pullRequest, I noticed that after the person do a review, he don’t show anymore on the reviewRequests node, although it is possible to get the user reviews under the reviews node.

So today I just query all repos from the Organization and all opened pull requests looking for the given user whether he is under reviewRequests or if he have reviews under the reviews node. Is there any way to get the user pending or dismissed review requests in an easier way?

IMO it would be nice to be able to query a user review requests directly from the user node if possible.


#2

Hi @bruno-campos!

To make sure we’re on the same page, what I’m seeing is:

  • Right now, you’re looking to be able to fetch all of the review and review requests across all of the PRs in all of the Repos in your Organization.
  • Because review requests go away once a user actually submits their review, you have to fetch both review request and reviews on each PR (this is necessary to get the state of their reviews anyway)
  • You’re looking for an easier solution to build a listing of all of the PR review requests, reviews, and their current state - maybe by looking at the individual user instead of going across all of the repositories.

Am I reading that right? Let me know if I’m not!

Thinking about this, I think it’s an interesting idea, but I think the implementation and interface might be very complicated - looking at a single users would bring in all of the requests and reviews that they’ve done across not only the repositories in your organization but anything that they’ve done on open source or personal projects that you have access to. This would require a lot of filtering on the connection in order for you to only get the repositories you’re looking for, which might make the API just as complex as the query you’re currently running.

I’d be curious to see what your current GraphQL query looks like, if you wouldn’t mind sharing?


#3

Hi @nickvanw!

Thank you for the answer! Yes, you are reading that right!

Just on the end, about listing all of PR review requests, currently I’m trying to filter reviews that need the user input (pending or dismissed), so the user knows which PRs he need to review (after changes or for the first time).

I agree that having this on user might get complicated, I was just thinking about that because for what I am using, it would be a nice fit. But if we could have a single point inside the pullRequest to get info about current review request state, it would also be nice (or even inside the Organization or repository, and filter requests by author).

I still need to test this behavior to be 100% sure, but it looks like, if a user approve a PR, and then comment on it, the last review on the reviews node will have state COMMENTED but the state of his whole review is actually APPROVED (again, I’m not 100% sure about this). That’s why I ignore COMMENTED states. But at the same time, if the user is requested to review a PR and just comment, his review state will be COMMENTED. So I would say that at least having a single point to easily get current user review state on a PR would be very useful.

About my current GraphQL, it looks like this:

query($login:String!, $organization:String!) {
  organization(login: $organization) {
    repositories(last:50) {
      nodes {
      pullRequests(states:OPEN, last:50, orderBy:{field:CREATED_AT, direction:DESC}) {
        nodes {
          title
          url
          reviews(last:1, author:$login, states:[DISMISSED,PENDING,APPROVED,CHANGES_REQUESTED]) {
            nodes {
              createdAt
              state
              author {
                login
              }
            }
          }
          reviewRequests(last:50) {
            nodes {
              reviewer {
                login
              }
            }
          }
        }
      }
    }
    }
  }
}

We are using last:50 because we are a small team, but if we had more people those numbers would be bigger.

Extracted from here: https://github.com/CareMessagePlatform/octoscout/blob/master/scripts/lib/gh-query.coffee


#4

Hi again @bruno-campos!

This is really helpful! Something that struck me as interesting was that, if I’m understanding correctly, you’re wanting to pull this information for only PRs that require review (that hasn’t happened yet) in order to merge, is that correct?

If so, would it be helpful to have an attribute on a PR to indicate whether someone has already approved it or not? Or, in other words, whether the “merge state” of the PR is green based on reviews? That would allow you to not need to worry as much about COMMENTED vs APPROVED, if I’m thinking properly?

Let me know! I think there are a few avenues here, and I would like to play around with the API a little bit around reviews as well, as I think you’ve raised some good questions about review behavior.


#5

Hey @nickvanw!

Yes, that’s exactly it! I want to pull information for only PRs that require review from a given user.

About this:

If so, would it be helpful to have an attribute on a PR to indicate whether someone has already approved it or not?

If the attribute is an array of nodes of current review states from users that reviewed or were requested to review it would be nice. A single attribute whether the merge state is green based on reviews wouldn’t be useful for this specific case because I’m trying to show a given user his current pending reviews (so if the user miss some email he don’t need to go through all projects looking for PRs that is waiting his action or wait for the PR owner to ping him for review).

For example, if we had something like (don’t mind the names):

pullRequest {
  nodes {
    currentReviewSates(filter by user) {
      nodes {
        user {
          login
        }
        state
      }
    }
  }
}

Would be useful already to get a user review state without the need to merge info from reviewRequests and reviews.

Again, thanks for the interest in this :smiley:


#6

Hey @bruno-campos!

Thanks for talking with me about this! I’m going to take this back to the team to see what we can do to make this a bit smoother. We’ll update this issue when anything changes!