automerge: run on failed merge_group events

[carlocab]

Closes #172999 (maybe)

[carlocab]

This depends a lot on Homebrew/actions/find-related-workflow-run-id, and whether it can find the associated PR based on the merge_group run.

[ZhongRuoyu]

So the logic is: click "merge when ready", merge group CI fails, then automerge is run where the real merge happens?

The "merge group CI fails" part could be a bit counterintuitive, but I guess this does work provided merge group CI fails in appropriate cases.

[MikeMcQuaid]

The "merge group CI fails" part could be a bit counterintuitive

I think this is probably unavoidable given that:

• you cannot commit to a PR inside a merge group itself and have those commits merged as part of the same merge group
• the hook for the "merge when ready" button is the merge group event

I'd be happy with this as a solution 👍🏻

[MikeMcQuaid]

Makes sense to me! Worth a try, thanks for this @carlocab!

[Bo98]

Is there a risk of an infinite loop here?

[carlocab]

Is there a risk of an infinite loop here?

Possibly, yes. It seemed like a possibility to me as I was writing this down, but I haven't yet worked out definitively either way.

[MikeMcQuaid]

@carlocab could consider applying a label at some stage as a marker to avoid this?

[carlocab]

I had to rework this.

This depends a lot on Homebrew/actions/find-related-workflow-run-id, and whether it can find the associated PR based on the merge_group run.

Unfortunately, find-related-workflow-run-id cannot find the associated PR based on the merge_group run.

This meant I had to write a new GraphQL query that does find the associated PR. I've also written another query that checks the PR timeline for removed-from-merge-queue events so that we can exit with an error when we see too many of those (in order to avoid infinite loops).

However, there is still quite a bit of overlap with the automerge.yml workflow. I'd be happy to see the overlap deduplicated, but I've already exceeded the time I allocated to this PR. I'd appreciate if someone else picked that up. (Or I can return to it at a later date.)

[carlocab]

@carlocab could consider applying a label at some stage as a marker to avoid this?

I took the more direct approach of checking the PR timeline for too many removed-from-merge-queue events.

[MikeMcQuaid]

Great work @carlocab!