forked from molecule-ai/molecule-core
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> |
||
|---|---|---|
| .. | ||
| auto-promote-staging.yml | ||
| block-internal-paths.yml | ||
| canary-staging.yml | ||
| canary-verify.yml | ||
| ci.yml | ||
| codeql.yml | ||
| e2e-api.yml | ||
| e2e-staging-canvas.yml | ||
| e2e-staging-saas.yml | ||
| e2e-staging-sanity.yml | ||
| promote-latest.yml | ||
| publish-canvas-image.yml | ||
| publish-workspace-server-image.yml | ||
| retarget-main-to-staging.yml | ||