Add --auto-merge filtering to gh pr list#7387
Conversation
|
Please let me know if the GraphQL paging commit should be split out to a separate PR. One of these days GitHub is going to implement a decent stacked diffs feature so we can keep interdependent commits together while allowing reviewers to focus on the individual diffs! |
c460be3 to
3503ef8
Compare
Consolidate the GraphQL page-fetching loops into one method, with each variant providing a struct to handle the different response types.
Because the API doesn't support filtering by autoMergeRequest status, the API responses are filtered locally.
3503ef8 to
05ce139
Compare
There was a problem hiding this comment.
Hmm, I must admit I'm not convinced of the utility of client-side filtering in this case. If a server-side filter does not exist for this, then I would rather opt to not expose this kind of filtering in the list command.
You have already exposed --json autoMergeRequest, so I would vote in favor of consuming that manually.
Others: thoughts?
|
Thanks @samcoe. @mjpieters Closing this because we do not believe that client-side filtering is the way to go. If someone really needs to filter based on auto-merge information, they can consume |
This PR is part of a series for issue #7309, adding auto-merge status support to PR commands
Add the ability to filter the
gh pr listPRs on their auto-merge status. There is no server-side support for this, so entries are filtered when retrieving the list of PRs from GraphQL.Because the list now is (further) filtered on the client side, the total number of PRs after filtering can't be known exactly until you fetch all pages, which would be inefficient and wasteful, so instead the total is marked as an upper bound and the text changes from Showing MATCHED of TOTAL to Showing MATCHED of up to TOTAL unless the last page was reached during local filtering.
$ gh pr list --auto-merge disabled Showing 30 of 35 pull requests in cli/cli that match your search ...There are two commits here; the first commit refactors the
pr/list/http.gocode to consolidate the GraphQL paged-result handling for the twoPullRequestListandPullRequestSearchfunctions into a singlefetchPullRequests()function that can handle GraphQL paging for either. This makes it then far easier to add client-side filtering to this single function rather that having to duplicate the effort.