ci: subscribe CI to merge_group events

[MegaRedHand]

Motivation

GitHub's merge queue runs required checks against a temporary gh-readonly-queue/* branch, and it only reports a workflow as passing if that workflow subscribes to the merge_group event (docs).

Lint and Test live in CI, which only listened to push, pull_request and workflow_dispatch. If those are set as required checks, the queue would sit waiting on checks that never start.

Description

• Add the merge_group: trigger to .github/workflows/ci.yml.
• Note in the concurrency comment that merge_group runs carry no head_ref, so the group falls back to the unique run_id and queue runs are never cancelled by a sibling run.

Only CI is changed; the other workflows are not required checks for merging.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[github-actions]

🤖 Kimi Code Review

This is a CI configuration change only (.github/workflows/ci.yml) with no impact on consensus-layer code. The modifications are correct:

Line 11: Addition of merge_group: trigger is required for GitHub merge queue support. This allows the Lint and Test jobs to run against the temporary merge branch created by the queue.

Lines 18-20: The concurrency comment accurately describes the fallback behavior. The expression ${{ github.head_ref || github.run_id }} correctly handles merge_group events (which lack head_ref) by using the unique run_id, preventing unintended cancellation of queued runs while preserving the cancel-in-progress behavior for regular PRs.

Security consideration: The merge_group trigger runs in the context of the target branch (typically main), which is appropriate for a repository requiring the existing branch protection rules. No supply chain risks introduced.

Verdict: LGTM. Standard GitHub Actions boilerplate for merge queue enablement.

---

Automated review by Kimi (Moonshot AI) · kimi-k2.5 · custom prompt

[github-actions]

🤖 Claude Code Review

No if: conditions gate the jobs on event type, so this is a clean, minimal, correct change.

Review: ci: subscribe CI to merge_group events

This is a small, well-scoped CI configuration change. It does exactly what it says.

Correctness

• Adding merge_group: to the on: triggers is the documented and correct way to get required-status-check workflows to run against GitHub's merge queue. Confirmed the lint and test jobs have no if: conditions gating on github.event_name, so both will actually execute when triggered by merge_group — no dead trigger.
• The concurrency group comment update is accurate: github.head_ref is empty for merge_group events, so the group key correctly falls back to github.run_id, meaning queue runs won't be cancelled by unrelated pushes. This is desirable behavior — you don't want a merge-queue validation run cancelled by an unrelated unrelated unrelated concurrency collision (the run_id is unique per run, so distinct merge-queue entries never share a group, but this also means two runs for the same queued entry would never cancel each other either — that's fine since merge_group events aren't re-triggered by pushes to the temp branch).

Scope

• Correctly limited to ci.yml only, matching the PR description's claim that other workflows aren't required checks.

Minor observations (non-blocking)

• merge_group: with no filters (no branches:) will trigger for merge queues targeting any base branch, which is fine here since main is the only queue-eligible branch in this repo.
• No changes needed to the pull_request/push triggers or job logic — this is additive and low-risk.

No bugs, security issues, or maintainability concerns found. Good to merge.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[github-actions]

🤖 Codex Code Review

1. Minor maintainability issue at .github/workflows/ci.yml: the comment says in-progress runs are cancelled for the same “PR or branch”, but group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }} only groups pull_request runs. On push and merge_group, github.head_ref is empty, so the key falls back to the unique run_id and older branch runs are not cancelled. If branch-level cancellation is intended, key on a stable ref; otherwise tighten the comment so it matches behavior.

No correctness, security, memory-safety, or consensus-layer findings beyond that. The merge_group trigger addition itself looks appropriate for merge-queue CI, and this PR does not touch fork choice, attestation handling, state transition, XMSS, or SSZ paths.

Testing gap: I reviewed the diff and workflow file only; I did not execute the GitHub Actions workflow locally.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt