OSAC-3734: add auto-queue workflow for merge queue - #216
Conversation
Automatically enables auto-merge on every non-draft PR from org members. When all required checks pass (E2E + label-gate), the PR enters the merge queue without any manual click. Uses pull_request_target for fork PR compatibility (all OSAC PRs come from forks). Safe because the workflow never checks out fork code. Uses MERGE_QUEUE_TOKEN secret (PAT or GitHub App token) since GITHUB_TOKEN may not have permission to enable auto-merge with merge queue enabled. External contributors (non-org members) are excluded — they use manual "Add to merge queue" after ok-to-test authorization. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: omer-vishlitzky <omer.vishlitzky@gmail.com>
|
@omer-vishlitzky: This pull request references OSAC-3734 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: omer-vishlitzky The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
WalkthroughThe auto-queue workflow now authenticates pull request merges with ChangesMerge queue authentication
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 11✅ Passed checks (11 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/auto-queue.yml:
- Around line 18-19: Update the top-level workflow configuration in
auto-queue.yml by adding an explicit permissions: {} block. Keep the existing
MERGE_QUEUE_TOKEN usage in the gh pr merge step unchanged, ensuring the
pull_request_target workflow does not inherit repository or organization default
GITHUB_TOKEN permissions.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 115fbebb-4e86-4de7-82d3-f678b260d78d
📒 Files selected for processing (1)
.github/workflows/auto-queue.yml
| GH_TOKEN: ${{ secrets.MERGE_QUEUE_TOKEN }} | ||
| run: gh pr merge ${{ github.event.pull_request.number }} --repo ${{ github.repository }} --auto --rebase |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
workflow=".github/workflows/auto-queue.yml"
if ! rg -q '^permissions:\s*\{\}\s*$' "$workflow"; then
echo "Missing explicit permissions: {} in $workflow" >&2
exit 1
fi
rg -n 'permissions:|GH_TOKEN:|github\.token|MERGE_QUEUE_TOKEN' "$workflow"Repository: osac-project/osac
Length of output: 224
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
workflow=".github/workflows/auto-queue.yml"
printf '--- file lines ---\n'
cat -n "$workflow" | sed -n '1,220p'
printf '\n--- relevant permissions/env/token searches ---\n'
rg -n '^\s*permissions:|GH_TOKEN:|GITHUB_TOKEN|github\.token|MERGE_QUEUE_TOKEN|gh pr merge' "$workflow" || true
printf '\n--- referenced PR workflow snippets: lines 1-80 ---\n'
sed -n '1,80p' "$workflow"Repository: osac-project/osac
Length of output: 246
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
workflow=".github/workflows/auto-queue.yml"
printf '%s\n' '--- file lines ---'
cat -n "$workflow" | sed -n '1,220p'
printf '%s\n' ''
printf '%s\n' '--- relevant permissions/env/token searches ---'
rg -n 'permissions:|GH_TOKEN:|GITHUB_TOKEN|github\.token|MERGE_QUEUE_TOKEN|gh pr merge' "$workflow" || true
printf '%s\n' ''
printf '%s\n' '--- referenced PR workflow snippets: lines 1-80 ---'
sed -n '1,80p' "$workflow"Repository: osac-project/osac
Length of output: 1689
🌐 Web query:
GitHub Actions workflows top-level GITHUB_TOKEN permissions default write contents pull_request_target
💡 Result:
In GitHub Actions, the GITHUB_TOKEN is a short-lived authentication token generated for each workflow job [1][2]. Its default permissions are governed by repository or organization settings [3][1]. Default Permissions By default, GitHub repositories may be configured to grant the GITHUB_TOKEN read and write access for all scopes, or a more restricted "read contents" default [3][1]. Because these defaults can be permissive, GitHub security documentation strongly recommends adopting the principle of least privilege by explicitly configuring permissions within the workflow file [4][5]. The pull_request_target Event The pull_request_target trigger is inherently different from the standard pull_request event [6][7]. While the standard pull_request event runs using the code from the pull request's merge commit and is restricted to a read-only GITHUB_TOKEN (without secret access) to prevent abuse [6][8], the pull_request_target event runs in the context of the base repository's default branch [6][7]. Because the pull_request_target event executes code trusted by the base repository, it is granted access to repository secrets and a GITHUB_TOKEN that defaults to read/write permissions [6][7]. If a workflow triggered by pull_request_target checks out code from an untrusted fork without careful handling, it creates a significant security risk by exposing these elevated privileges to potentially malicious code [6][7]. Best Practices for Hardening To secure your workflows, you should: 1. Explicitly set permissions: Use the permissions key at the workflow or job level to restrict the GITHUB_TOKEN to only the necessary scopes [1][4]. It is a recommended security practice to set the default to empty (permissions: {}) and then grant only required access [9]. 2. Limit GITHUB_TOKEN scope: Use the principle of least privilege to ensure the token has only the minimum access required to perform its task [4][5]. 3. Handle pull_request_target with caution: When using pull_request_target, ensure that any code checked out from a fork is handled safely and that secrets or high-privilege tokens are not inadvertently exposed [6][7].
Citations:
- 1: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
- 2: https://docs.github.com/en/actions/concepts/security/github_token
- 3: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
- 4: https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
- 5: https://docs.github.com/en/actions/reference/security/secure-use
- 6: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 7: https://www.sysdig.com/blog/insecure-github-actions-found-in-mitre-splunk-and-other-open-source-repositories
- 8: https://docs.github.com/en/enterprise-cloud@latest/actions/reference/security/securely-using-pull_request_target
- 9: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.md
Set an explicit token policy for this workflow.
This pull_request_target workflow only uses MERGE_QUEUE_TOKEN in the step that runs gh pr merge; it does not need GITHUB_TOKEN write access. Add a top-level permissions: {} block so repository or organization default permissions cannot grant unused write scopes.
Proposed fix
+permissions: {}
+
jobs:
enable-auto-merge:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/auto-queue.yml around lines 18 - 19, Update the top-level
workflow configuration in auto-queue.yml by adding an explicit permissions: {}
block. Keep the existing MERGE_QUEUE_TOKEN usage in the gh pr merge step
unchanged, ensuring the pull_request_target workflow does not inherit repository
or organization default GITHUB_TOKEN permissions.
Source: Path instructions
2 participants
Summary
Automatically enables auto-merge on every non-draft PR from org members. When all required checks pass (E2E + label-gate), the PR enters the merge queue without any manual click — same UX as Tide.
How it works
gh pr merge --auto --rebase→ enables auto-merge on the PRToken
Uses
MERGE_QUEUE_TOKENrepo secret (fine-grained PAT or GitHub App token) withpull-requests:write+contents:writepermissions scoped toosac-project/osac. GITHUB_TOKEN may not have permission to enable auto-merge when merge queue is required.Security
pull_request_targetso the token works for fork PRs (all OSAC PRs come from forks)gh pr merge --autoauthor_associationcheckPrerequisites
MERGE_QUEUE_TOKENrepo secret with a PAT (scoped toosac-project/osac, permissions:pull-requests:write+contents:write)Part of OSAC-3734 (merge queue migration)
label-gate.ymlworkflowauto-queue.ymlworkflowTest plan
🤖 Generated with Claude Code
Summary by CodeRabbit