Conversation
This is for symmetry with `issue list`. The problem is that the `Repository.pullRequests` connection doesn't support filtering by assignee, therefore we need to switch to search API in case an assignee was specified. This is awkward, but I don't see another way.
probablycorey
left a comment
probablycorey
left a comment
There was a problem hiding this comment.
It's a bummer about needing to switch to the search api :( But it doesn't add too much more code.
probablycorey
left a comment
probablycorey
left a comment
There was a problem hiding this comment.
Nice cleanup of the RunCommand method and pruning dead code!
My one concern is having the two different graphql queries PRs. It took me a bit to figure out why there were two paths. It seems like the only difference is that the search query can't handle multiple labels.
I'd rather have one code path with the limited label functionality than two paths. Or at least a comment describing why there are two paths.
Other than that, great work finding a work around to the pr assignee problem!
That's right. Your concerns re: multiple code paths are valid and I wish we could switch to just one completely, but right now this is the compromise I chose to take. My primary motivation to keep the |
…err_msg infer project name: improve err msg
2 participants
This is for symmetry with
issue list: #68 (comment)The problem is that the
Repository.pullRequestsAPI connection doesn't support filtering by assignee, therefore we need to switch to search API in case an assignee was specified. This is awkward, but I don't see another way.TODO:
--assignee+--state--assignee+--base--assignee+--label- note: multiple labels not supported in combination with--assignee(the Search API doesn't support label "OR" query)