Make it clear when a PR Is in the merge queue

[AntonNiklasson]

It would be nice to be able to see some kind of indicator that the pull requests is currently in the merge queue.

[robberwick]

@dlvhdr this would be super useful to me. Is this a feature that you'd like to see in the project? If so, would it be ok to work on this and see if I can knock together a PR?

[dlvhdr]

@robberwick definitely!
Let me know if you want to brainstorm or just talk over a pr

[dlvhdr]

Sounds good

[robberwick]

Sorry for the delay @dlvhdr - I wanted to test my dev build at work to make sure that it was going ot function as expected. Happily it did 🎉

Here is my branch diff against main: main...robberwick:gh-dash:merge-queue-status-indicator

The approach I've taken is to query the GitHub GraphQL API after a successful merge command to determine what actually happened, then update both the task completion message and the in-memory PR state accordingly.

The extra API call after a merge operation adds an overhead in terms of latency, but I couldn't find another way to distinguish between direct merge, merge queue addition, and auto-merge enablement.

While working on this, I also added equivalent support for auto-merge, since the same problem exists there. I've updated the row rendering logic to show a new icon for PRs with auto-merge enabled, following the same visual pattern as the merge queue indicator.

It's worth noting that this doesn't add the ability to explicitly enable auto-merge or control merge queue behaviour from the TUI — it only detects and displays the outcome when these features are triggered via the existing merge action.

Does this direction seem reasonable? Happy to adjust the scope or take a different approach if you'd prefer.

If you're broadly happy though, say the word, and I'll open a pr to continue discussion there.

[sideshowbarker]

The approach I've taken is to query the GitHub GraphQL API after a successful merge command to determine what actually happened, then update both the task completion message and the in-memory PR state accordingly.

The extra API call after a merge operation adds an overhead in terms of latency, but I couldn't find another way to distinguish between direct merge, merge queue addition, and auto-merge enablement.

I wonder if you could reliably infer the outcome from the PR state that gh-dash already has loaded:

• IsMergeQueueEnabled is false → direct merge
• IsMergeQueueEnabled is true and MergeStateStatus is CLEAN → will be added to queue
• IsMergeQueueEnabled is true and status is not CLEAN → auto-merge will be enabled

[sideshowbarker]

The approach I've taken is to query the GitHub GraphQL API after a successful merge command to determine what actually happened, then update both the task completion message and the in-memory PR state accordingly.

The extra API call after a merge operation adds an overhead in terms of latency, but I couldn't find another way to distinguish between direct merge, merge queue addition, and auto-merge enablement.

Alternatively, you could do a rewrite which replaces the current gh merge calls with direct GraphQL API calls to do the same thing. And then you just check the response from those. So, just one GraphQL call — rather than a subprocess call + GraphQL call.

[robberwick]

That's a good idea. I had been trying to keep my changes as minimal as possible, but if a refactor to the merge logic to use GraphQL api is acceptable, then that's definitely the better option. I'll take a crack at that. 👍

[robberwick]

I've not forgotten about this.. I have something working that I've been using myself for a couple of weeks, but I just want to kick the tyres on it a little more before raising the PR 😉

[robberwick]

ok, I think this is about ready for review and testing: #809

I've delilberately left in the somewhat meandering path to the current state, but if you'd like me to tidy up the history, just shout.