ci: add merge_group trigger to ci + codeql - #1982
Merged
Merged
Conversation
Pre-work for enabling GitHub merge queue on the staging branch (#TBD follow-up issue). Without these triggers, the queue's pre-merge CI run on the speculative `gh-readonly-queue/...` ref would never fire, every queued PR would show false-green for the required checks, and queue would merge things that don't actually pass on the rebased commit. Adding the trigger now is **a no-op** — the `merge_group` event only fires once the queue is enabled on a branch, which is a separate UI/API toggle. So this PR is safe to land in isolation; merge-queue enablement is the next step and reversible at the branch-protection level. Why these two workflows: - `ci.yml` provides 5 of the 8 required staging checks (Detect changes, Platform Go, Canvas Next.js, Python Lint & Test, Shellcheck E2E) - `codeql.yml` provides the other 3 (Analyze go / js-ts / python) Other workflows (e2e-staging-*, canary-*, publish-*) are not required status checks and don't need the trigger to keep the queue working. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
[Molecule-Platform-Evolvement-Manager]
Step 1 of 3 to enable GitHub merge queue on the `staging` branch.
Why
Today: 27 of 28 open staging PRs are stale (DIRTY/BEHIND/BLOCKED). `required_status_checks.strict=true` forces every PR to be up-to-date with staging head, so each merge invalidates every other open PR. Agents are filing PRs faster than they can rebase them. The drop-stale endpoint that would fix the queue overflow (#1950) is itself stuck BEHIND staging — circular.
GitHub merge queue is the standard answer (Rust's bors since ~2013, Kubernetes' Tide, Google/Meta internal, GitHub itself, Shopify, Stripe, Datadog). It auto-rebases each PR against fresh staging head, runs CI on the rebased commit, merges if green, picks the next one.
What this PR changes
Adds `merge_group: { types: [checks_requested] }` to the two workflows that produce required-status checks on staging:
Without this, the queue's pre-merge run on the speculative `gh-readonly-queue/...` ref would never fire, every queued PR would show false-green, and queue would merge unverified rebases.
Why this is safe to land in isolation
The `merge_group` event only fires once the queue is enabled on a branch (separate UI/API toggle). So today this PR is a no-op — pure plumbing for step 2.
Sequence
Reversible at any step (toggle queue off in UI).
Other workflows checked
`e2e-staging-`, `canary-`, `publish-*` are not required status checks → no `merge_group` needed. `auto-promote-staging.yml` runs on push to staging only → also unaffected.