ci: improve release workflow for merge queue compatibility

[knqyf263]

Description

See #7722

Changes

1. Added a new job to iterate through multiple commits in the push event to check for release commits.
2. Modified subsequent jobs to use the outputs from this new job.
3. Replaced the /repos/{owner}/{repo}/git/refs API with Git commands due to API limitations.
4. Updated GitHub Actions configuration to address secret detection and workflow permission issues.

Detailed Explanation

API Replacement

We currently use the /repos/{owner}/{repo}/git/refs API to check for release commits. However, after implementing support for multiple commits, I encountered 404 errors. Local testing revealed that the API only works reliably with the head commit of any branch. This issue has been reported by other users as well.

To resolve this, I've switched to using Git commands instead of the API.

Secret Detection and Fetch Depth

When using Git commands, I encountered another issue where setting fetch-depth: 1 resulted in secret detection preventing pushes.

Error

remote: error: GH013: Repository rule violations found for refs/tags/v0.57.0.        
remote: 
remote: - GITHUB PUSH PROTECTION        
remote:   —————————————————————————————————————————        
remote:     Resolve the following violations before pushing again        
remote: 
remote:     - Push cannot contain secrets        
remote: 
remote:             
remote:      (?) Learn how to resolve a blocked push        
remote:      https://docs.github.com/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line#resolving-a-blocked-push        
remote:             
remote:      (?) This repository does not have Secret Scanning enabled, but is eligible. Enable Secret Scanning to view and manage detected secrets.        
remote:      Visit the repository settings page, https://github.com/knqyf263/trivy/settings/security_analysis        
remote:             
remote:             
remote:       —— GitHub SSH Private Key ————————————————————————————        
remote:        locations:        
remote:          - blob id: 68e459e1a8c71b2d57fe666486e67af03ecbabf7        
remote:             
remote:        (?) To push, remove secret from commit(s) or follow this URL to allow the secret.        
remote:        https://github.com/knqyf263/trivy/security/secret-scanning/unblock-secret/2nQ281VzLwsLLtEuKjux9VdVowG        
remote:             
remote:             
remote:     ——[ WARNING ]—————————————————————————————————————————        
remote:      Scan incomplete: This push was large and we didn't finish on time.        
remote:      It can still contain undetected secrets.        
remote:             
remote:      (?) Use the following command to find the path of the detected secret(s):        
remote:          git rev-list --objects --all | grep blobid        
remote:     ——————————————————————————————————————————————————————

This doesn't occur with local pushes. To resolve this, I've set fetch-depth: 0. While we could allow the detected secret (which is a test secret and a false positive), I've opted for the fetch-depth: 0 solution to prevent potential issues during future releases.

GitHub Token Permissions

I discovered that using secrets.GITHUB_TOKEN causes errors when the commit includes workflow changes:

! [remote rejected]     v0.57.0 -> v0.57.0 (refusing to allow an OAuth App to create or update workflow `.github/workflows/release-please.yaml` without `workflow` scope)

Others are also facing this issue. To prevent hard-to-diagnose errors in case workflow changes are included with release PRs in the merge queue, I've switched to using secrets.ORG_REPO_TOKEN which has the workflow scope.

Test Run

A successful test run of the updated workflow can be found here:
https://github.com/knqyf263/trivy/actions/runs/11322890634/job/31484563456

Related issues

• Close ci: release workflow incompatibility with merge queue #7722

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[knqyf263]

After spending several hours, I realized that this problem could be solved by setting the "Maximum group size" to 1...

This PR was added to the merge queue along with another PR, but the release workflow was properly triggered. I just wasted my days 😭