Merge queue concurrency does not abort other actions on failure

[FluffyGhoster]

Select Topic Area

Product Feedback

Body

Hello there,

we are running the merge queues with the concurrency option enabled, and I have noticed something that I find unexpected, assume the following scenario:

The merge queue contains 3 PRs:

• PR1
• PR2
• PR3

The concurrency is set to 3+ in the repository
Three actions are dispatched and goes in processing

Now, assume that PR1 fails the status check, the merge queue recreates the new actions jobs for PR2 and PR3 as per https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#failing-ci

However, for what I am seeing, the previous actions do not seem to be aborted, keeping the runners busy for actions whose result doesn't matter (since they were recreated without PR1)

Is there a way to make the merge queue abort those unnecessary jobs, to expeditely free up runners for the new ones? How?

I see that there is a webhook merge_group.destroyed (https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=destroyed#merge_group) but I do not see a way to subscribe to it in the workflow, the only supported value of types that I see is checks_requested

Thank you

[ultratin]

Following this as well. Having our self hosted runners continuing running stale CI while taking up merge queue concurrency doesn't really make sense.

[ultratin]

Found a solution by the community which cancels previous runs of the same workflow. It might help, but needs to be tested. https://pierreraffa.medium.com/github-merge-queue-f25203f46220
https://github.com/PierreRAFFA/cancel-previous-runs-action

[FluffyGhoster]

This is a nice finding, thank you for the heads up!

I would still prefer (even if it works flawlessy after testing) that github would support this natively, as it seems to me reasonable it should, though