regression-gate never gates: the merge queue is bypassed by admin merges

Open
  • Is something wrong?
#1,926 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
70/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
github-actions
Domain
ci-cd

Research direction

Start at .github/workflows/regression.yml and its on: triggers, then look at how the other workflows handle post-merge runs and at the tree-identical guard described in issue #1925. Decide which of the three options (2 is suggested) you are implementing: add a push-to-master trigger and/or correct the merge-queue wording in CLAUDE.md. Done looks like regression running automatically on merges plus documentation that matches reality; note that the ruleset/queue part (option 3) may need maintainer access, not code.

Written by the indexing model from the issue text.

Description

Not a misconfiguration — a consequence of a deliberate choice, written down because the current state is easy to misread as protection that exists.

What is actually true

The master ruleset has a merge_queue rule and four required checks: build, CI-Test-group-Fast, CI-Test-group-Quarkus, regression-gate.

merge_group has never fired — zero runs, ever, across every workflow.

The reason is simple and intentional: merges are done with gh pr merge --admin, because the 1-review requirement usually cannot be satisfied (there is frequently no second reviewer available). --admin bypasses both the review requirement and the queue.

What follows from that

  • regression-gate gates nothing. Only the merge queue produces it, so regression.yml runs only when kicked by hand (gh workflow run regression.yml --ref master) or on the nightly schedule. That manual step is already documented in CLAUDE.md, which is the tell: a gate you have to remember to pull is not a gate.
  • The post-merge push to master is the only automatic validation of a merged result. That matters for #1925, which skips that run when the merge tree is identical to the branch — safe precisely because the branch run covered the same tree, but it does mean the fast lane, not the queue, is the real safety net.
  • CLAUDE.md describes "a merge queue that runs the full suite before landing". That has never happened.

Options

  1. Document it and move on. Change CLAUDE.md to say regression is a post-merge manual/nightly check rather than a landing gate, and keep the habit of kicking it after an admin merge. Zero cost, no false sense of a gate.
  2. Make regression a real post-merge check — trigger regression.yml on pushes to master. It then runs automatically on exactly the thing that landed, without needing the queue or a reviewer. Costs ~9 minutes of runners per merge, and would want the same tree-identical guard as #1925 so it does not re-run on a tree the branch already covered.
  3. Make the queue usable — drop the review requirement to 0 (keeping the checks), so merges can go through the queue normally and regression-gate gates for real. This trades a review requirement that is not being met anyway for a suite that would then actually run before landing.

I would suggest 2, optionally with 1: it gets regression running automatically on what landed, without pretending a review will appear.

Worth deciding rather than drifting

The risk today is not that anything is broken — regression does get run, by hand and nightly. It is that the ruleset looks like it enforces a full suite before landing, so someone reasonably assumes a merged commit has passed one.

Dominant language
Java
Stars
140
Forks
35
Avg merge
17h 39m
Merged PRs (30d)
19

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from virtualcell/vcell

All issues in virtualcell/vcell

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.