BUG: gh pr list and issue list --label uses OR logic instead of AND logic #419
Copy link
Copy link
Closed
Labels
bugSomething isn't workingSomething isn't workingpriority-2Affects more than a few users but doesn't prevent core functionsAffects more than a few users but doesn't prevent core functions
Description
Describe the bug
gh pr list --labelappears to be using OR logic instead of AND logicgh pr list --labelsometimes contains duplicates.
To show why this is a problem, imagine your PRs have the following labels:
in progress,ready for review, andreviewedteam a,team b, andteam c.
Now let's say you want to find all of the PRs that are ready for review from team b.
So it makes sense that you try to search for --label "ready for review,team b". However, instead of getting a list of every PR that is both "ready for review" and "team b," you get:
- Every PR labeled "ready for review," even if it is not from "team b."
- Every PR labeled "team b," even if it is not "ready for review."
These results are useless from the perspective of someone who wants to review PRs from team b that are ready for review.
$ gh --version
gh version 0.5.4 (2020-02-04)
https://github.com/cli/cli/releases/tag/v0.5.4
Steps to reproduce the behavior
- Create a PR named "Example A" with labels
test-aandtest-c - Create a PR named "Example B" with labels
test-bandtest-c - Run
gh pr list -l test-a,test-c
Expected vs actual behavior
Expected:
Pull requests for ...
#17874 Example A example-a
Actual:
Pull requests for ...
#17875 Example B example-b
#17874 Example A example-a
#17874 Example A example-a
Broken expectations:
- I expected "Example B" to not appear at all, because it does not have the
test-alabel and therefore doesn't satisfy the given query. - I expected "Example A" to appear only once, because there is no point in having duplicates in this list.
Possible solutions
At minimum, use AND by default.
Ideally, support full boolean logic:
gh pr list -l "team a AND (ready for review OR NOT in progress)"Logs
$ gh pr list -l test-a
Pull requests for ...
#17874 Example A example-a
$ gh pr list -l test-b
Pull requests for ...
#17875 Example B example-b
$ gh pr list -l test-c
Pull requests for ...
#17875 Example B example-b
#17874 Example A example-a
$ gh pr list -l test-a,test-c
Pull requests for ...
#17875 Example B example-b
#17874 Example A example-a
#17874 Example A example-a
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't workingpriority-2Affects more than a few users but doesn't prevent core functionsAffects more than a few users but doesn't prevent core functions
Activity
billygriffin commentedon Feb 14, 2020
Thanks for the issue! Just want to note that this is also relevant for issues. We're going to discuss this and determine a way forward.
[-]BUG: gh pr list --label uses OR logic instead of AND logic[/-][+]BUG: gh pr list and issue list --label uses OR logic instead of AND logic[/+]billygriffin commentedon Feb 14, 2020
After a discussion, we agree and think that the best way forward here for now is to do what @dterhorst describes above, mirroring how github.com filters when there are multiple labels specified.
Proposed solution: If you have multiple labels specified, the list should only show those issues or PRs that match all of the specified labels, not any.
While we're also attracted to the idea of full boolean logic, we're going to punt on that for now until we get more signal that that's something a lot of people are going to want to use.
Note: We may be limited by what we get from the API to use AND logic instead of the existing OR logic, so we're discussing ways forward.
coot commentedon Jul 6, 2020
Is there any progress on this, the current behaviour is quite annoying and limiting.
mislav commentedon Jul 6, 2020
@coot We are waiting on the corresponding GraphQL APIs to be finalized on the platform side.
coot commentedon Jul 6, 2020
@mislav thanks for letting me/us know
matschaffer commentedon Oct 14, 2020
Looks like about a quarter since the last update. Was hoping to use
hubin one less place but this means I'll be keeping it around for the time being.Any news on the GraphQL APIs?
mislav commentedon Oct 14, 2020
@matschaffer Thanks for checking in! We got access to some APIs for this that are under preview (not available to the general public) but we will likely need a few more weeks to ship something built on top of that. 🙇
matschaffer commentedon Oct 14, 2020
Thanks for the update!
andysanders commentedon Feb 17, 2021
Hey Guys.
What's the latest on this one? It would be super helpful for all sorts of planning exercises.
Our use case is similar to the original enquirer. But ticket type rather than team.
e.g. Priority: High, Medium, Low
Type: Bug, Enhancement, Help
I have a team focused on all High Priority Bugs. So being able to search for issues with labels 'Bug' AND 'High Priority' would be super helpful.
Thank you.
mislav commentedon Mar 9, 2021
@andysanders No updates yet. We will likely have to switch to the Search API internally to get AND labels.
In the meantime, you can query the Search API directly:
chore!: set Agent property load_tools_from_directory to default to Fa…