ci: release workflow incompatibility with merge queue

[knqyf263]

Current Behavior

Our release workflow is triggered when commits are pushed to the main branch. It creates a tag if the head commit message starts with release:. These "release PRs" are automatically generated by Release Please.

trivy/.github/workflows/release-please.yaml

Line 43 in 31aa20a

if: ${{ startsWith(github.event.head_commit.message, 'release:') }}

Problem

We've discovered that this workflow doesn't work correctly when combined with the merge queue. According to the GitHub documentation when multiple PRs are added to the merge queue, they are batched together before being merged into the target branch.

The merge queue creates a temporary branch with the prefix of main/pr-2 that contains code changes from the target branch, pull request #1, and pull request #2, and dispatches webhooks.
When the GitHub API receives successful CI responses for merge_group branches main/pr-1 and main/pr-2, the temporary branch main/pr-2 will be merged in to the target branch. The target branch now contains both changes from pull request #1 and #2.

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue#successful-ci

This means that if a release PR is in the merge queue and other PRs are added to the queue, multiple commits will be pushed to the target branch simultaneously. As a result, the head commit may not start with release:, causing the release workflow to fail.

Proposed Solution

The push event payload contains a commits array. Instead of checking only the head_commit, we should examine all commits in the push event to determine if a release should be triggered.

[knqyf263]

I've observed that PRs added later in the merge queue incorporate the changes of PRs added earlier together, as we understand.

[knqyf263]

I set "maximum pull requests to merge" to 1, which seems to solve the problem.