GitHub Community
How do I search for PRs with conflicts? #23152
-
|
I am trying to filter search results for PRs with conflicting files such that it says this in the PR: There doesn’t seem to be any information on this in the documentation: Searching issues and pull requests - GitHub Docs |
Beta Was this translation helpful? Give feedback.
Replies: 9 comments 3 replies
-
|
@aaronfranke - Great question! There’s not a specific qualifier in our search interface that would allow you to fetch a list of pull requests and filtering them for those with conflicting files. One alternative approach that might be of interest is using our GraphQL API to fetch a list of pull requests and obtaining their number, URL and Here’s an example using the Here’s the result set at this time of writing: You could adapt this approach for a different repository or a set of repositories scoped under an account or organization. I highly recommend checking out our documentation covering the GitHub GraphQL API, in addition to our guides if you haven’t already. I hope this helps! |
Beta Was this translation helpful? Give feedback.
-
|
There are now several actions in the Github Marketplace that will check for PRs with conflicts and add a label to them, allowing the list to easily be filtered by that label. I think that’s the route I’m going to take. (Though it sure would be nice if Github’s PR list automatically displayed an icon for conflicting PRs. The same way it does for PRs with linked issues, and for issues with linked PRs.) |
Beta Was this translation helpful? Give feedback.
-
|
Took a little auditioning and experimentation, but I now have a Github Actions workflow for eps1lon/actions-label-merge-conflict installed in both of our project repos that receive regular PR contributions. So far it seems to be working out well, every time there’s a push to our default branch, it scans all of the open PRs for detected conflicts, adds a label of my choosing, and leaves a comment on the PR (to generate an email notification to the submitter). If you do decide to try it out, though, be sure you write your workflow so that it instead of the version 2.0.0 that’s listed as the latest release at the project page. 2.0.0 has a bit of a retry-timeout-cascade problem thing that predictably hit us on our very first outing with it, so that I had to stop the workflow after a solid 30 minutes of spinning its wheels fruitlessly. 2.0.1 generally completes in under 5-10 minutes. (There’s some expected lag to the whole process, because Github’s conflict-detection jobs are processed asynchronously… so any tool that acts on them has to be prepared to wait for those results to show up, after there’s activity on the branch.) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the info and actions, they can be helpful. But in the end it’s a second best solution, might be better to have the green tickbox on the PR on the GitHub UI also turning red. It now stays green. |
Beta Was this translation helpful? Give feedback.
-
|
@valentijnscholten Changing the color of the icon without changing the shape would impair the interface accessibility, as it would be undetectable to anyone with any sort of red-green colorblindness (the most common types). Also, conflicts are independent of CI passing — IOW, you’d want to know when there are conflicts even if the CI status is a red X (CI failed) or a yellow bullet (CI in progress). |
Beta Was this translation helpful? Give feedback.
-
|
Maybe I meant that it should become a red cross or something else red. Even if the CI passes, the PR is not ready to merge due to the merge conflicts. They have to be resolved first en probably CI has to run again before it can be merged. So any sort of indicator that the PR is conflicted is helpful. And maybe in my mind the “have no conflicts” is mandatory to conclude a PR has “passed CI succesfully”. For now I have resorted to the GibHub Action promoted by GitHub to label conflicted PRs on every merge to dev. |
Beta Was this translation helpful? Give feedback.
-
|
How can I filter for PRs with conflicts in the GraphQL API? The query @francisfuzz posted will show the mergeable status, but I haven't figure out how to filter by it in the initial query. I want to search in rust-lang/rust, which has 600+ open PRs and hits the rate limits on the query explorer. |
Beta Was this translation helpful? Give feedback.
-
|
It looks like the REST API doesn't return the mergeable status, so GraphQL it the only way to do this today. |
Beta Was this translation helpful? Give feedback.
-
|
With github cli ( gh api graphql -F owner=org -F name=repo -f query='query($name: String!, $owner: String!) {
repository(owner: $owner, name: $name) {
pullRequests(last: 100, states: OPEN) {
edges {
node {
title
number
url
author {
login
}
mergeable
state
}
}
}
}
}' | jq -r '.data.repository.pullRequests.edges[] | select(.node.mergeable != "MERGEABLE") | [.node.author.login, .node.title, .node.url] | @csv' | sort |
Beta Was this translation helpful? Give feedback.
-
|
That still hits the 100-PR rate limit, though. |
Beta Was this translation helpful? Give feedback.
-
|
@jyn514 You can use pagination to overcome that: gh api graphql --paginate -F owner=rust-lang -F name=rust -f query='
query($endCursor: String, $name: String!, $owner: String!) {
repository(owner: $owner, name: $name) {
pullRequests(first: 100, states: OPEN, after: $endCursor) {
edges {
node {
title
number
url
author {
login
}
mergeable
state
}
}
pageInfo {
hasNextPage
endCursor
} } } }'Will list all open PRs for rust-lang/rust, not just the first 100. |
Beta Was this translation helpful? Give feedback.
-
|
(They'll come out in oldest-first order, due to |
Beta Was this translation helpful? Give feedback.
@aaronfranke - Great question! There’s not a specific qualifier in our search interface that would allow you to fetch a list of pull requests and filtering them for those with conflicting files.
One alternative approach that might be of interest is using our GraphQL API to fetch a list of pull requests and obtaining their number, URL and
mergeablevalue. Themergeablefield can be one of three values, whereCONFLICTINGwould indicate that the pull request can’t be merged due to merge conflicts.Here’s an example using the
github/linguistrepository: