Enable testing merge queues @ GitHub Actions CI/CD

[webknjaz]

This allows org-hosted projects to start enabling merge queues in the repository settings. With that, GitHub would trigger a separate event against a merge commit derived from merging several pull requests with the target branch.

[jaraco]

IIUC, this PR proposed two changes:

• add "merge_group" to the set of actions on which this workflow runs.
• ignore gh-readonly-queue for pull requests.

Are both changes required to effect "Enable testing merge queues"?

[jaraco]

Where is gh-readonly-queue documented? Can we link to the authoritative documentation that recommends this change?

[webknjaz]

Here's where it's documented:

• https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#configuring-continuous-integration-ci-workflows-for-merge-queues
• https://github.com/orgs/community/discussions/46757#discussion-4836009

Though, there's no explicit mention of ignoring it. I think, it's because the examples there don't show the simultaneous use of both push and merge_group. This is something that wasn't immediately obvious to me and I got it wrong in a few repos (while it worked in others because they already filtered the branches before the change).

[webknjaz]

IIUC, this PR proposed two changes:

• add "merge_group" to the set of actions on which this workflow runs.

Yes, it just means that whenever this event is seen within the GitHub platform, it triggers this workflow run.

• ignore gh-readonly-queue for pull requests.

Are both changes required to effect "Enable testing merge queues"?

So the thing is that in order to function, GitHub's Merge Queues feature creates and updates branches prefixed with gh-readonly-queue/{base_branch} in the repository where the PR resides. End-users can't manage those branches in any way and they exist temporarily.
But what it means is that whenever GH manipulates those branches, a push event happens within the GitHub platform. This is happening as a result of updating the queues, which generate another event called merge_group.
As a result, there are always 2 events happening that are related to the same logical process within GitHub.
That doc I linked above suggests that third party CI services could just listen to the push events to those read-only branches, while showcasing the use of merge_group for GitHub Actions specifically. Although, I'm pretty sure that the third party GitHub Apps could be configured to receive those merge_group events just as well.

The examples there show pull_request and merge_group events in their snippets, which basically covers PR creation/updates and adding to the merge queue respectively. When there's a push trigger additionally, it causes a situation when there's two CI runs starting because push and merge_group happen concurrently, but kinda independently (GitHub Actions CI/CD doesn't know they are related). I saw cases where combined with the cancellation scopes, one (arbitrary) of those runs get cancelled by the platform (this is not currently configured in the skeleton).

Whenever a combination of PRs merged together with the main branch in a merge queue succeeds, GitHub merges that into main (through fast-forward, if allowed), which generates a new push event in the repository, basically for the same thing that was already tested.

It may be fine to just remove push. But in general, when we want to keep it, we can just filter out those duplicates through excluding the known branch pushes associated with the merge queues. Which is what this patch does.

Of course, there's another pre-existing (and orthogonal) source of double runs. push and pull_request when they're happening within the same repository (PRs originating from upstream). This is happening when the maintainers have a commit bit in the upstream repo and make topic branches right in there. Some people fight this with only allowing runs for pushes to the main branch.
This works, but doesn't solve another problem which exists because of using this approach — rubbish branches in various states at different points in time end up being copied to the forks and then, the contributors get a lot of unneeded branches that aren't useful, nor are kept up-to-date with the upstream.
At Ansible, we deal with this by disallowing any PRs from branches in upstream, essentially forcing anybody with commit bit to make PRs from forks, making the tree much cleaner, and this also doesn't cause double runs as a nice side effect. I personally adopted this approach for my other contributions, helping me keep other upstreams as clean.

[jaraco]

Thanks for the background and explanation!