PSA: Tracking my open PRs with merge conflicts

Development
1

One well-known problem in nixpkgs is how long it takes to get a review on some PRs. Though the average PR is merged in under a day, this average PR probably comes from the r-ryantm bot, not a human. Human PRs meanwhile can take weeks to get attention.

In the meantime, some PRs get merged, and this can lead to merge conflicts if my PR has touched the same files as a merged PR. And by the time my PR gets attention, it gets a comment about the conflict, then forgotten again for many more weeks. And if no one comments, I didn’t even know about it.

So, I wanted to be more proactive about tracking such PRs, and came up with the following query.

gh api graphql -f query='{
  user(login: "USERNAME") {
    pullRequests(last: 100, states: OPEN) {
      edges {
        node {
          number
          url
          baseRefName
          headRefName
          mergeable
          isDraft
        }
      }
    }
  }
}' | jq '.data.user.pullRequests.edges[] | select(.node.mergeable != "MERGEABLE")'

This requires prior authentication with the gh CLI, and jq on path as well.

Replace USERNAME of course, and I hope you don’t have over 100 open PRs…

Also, if you see a bunch of PRs with UNKNOWN mergeable status, rerun the query. I don’t know why this happens.

5 Likes
2

It would be interesting to have the statistics without r-ryantm indeed

That’s really neat, thanks!

out
out685Ă—602 37 KB

:sweat_smile:

1 Like
3

There’s a --paginate flag you can pass, though I didn’t look into it deeply yet.
Further docs are here: Using pagination in the GraphQL API - GitHub Docs

4

That comes from the fact that GitHub computes mergability of PRs lazily. The first run tells GitHub to start computing it, so that it’s available later. This get invalidated every time a push to the base branch happens, which is why this is done lazily. Otherwise GitHub needs to compute mergability of thousands of PRs everytime somebody pushes to master!