cc @mchmarny

Summary

Tighten the merge policy on main so that a PR cannot be merged until every merge-gating CI check that applies to that PR has completed successfully.

Current policy

Today the main branch ruleset gates merges on only 7 named checks:

• tests / Test
• tests / Lint
• tests / CLI E2E
• tests / E2E
• tests / Security Scan
• analyze
• malware-scan

Everything else that runs on a PR — GPU Smoke / Inference / Training tests, Docker Validator, Docker Manifest, ClamAV, grype, CodeQL, vuln-scan — is not in the required list. If any of those jobs is still running or has failed, a PR can still be merged as long as the 7 above are green.

Concrete example: PR #587 was merged to main while non-required GPU checks were still in flight. It merged successfully once the 7 required checks were green, and the GPU Inference / GPU Training jobs then failed later. This was not an admin-bypass case — it was merged normally under the current ruleset.

Why not "every check that ran"

GitHub rulesets do not provide a simple dynamic "require every check that ran" switch. Required status checks are configured explicitly.

There is also an important path-filter nuance:

• Job-level skips are fine — they report a successful/skipped check.
• Workflow-level skips from paths / paths-ignore are not fine for required checks — they can stay pending and block merge.

This repo already has workflow-level path filters in some workflows (for example actionlint, CodeQL, and vuln-scan), so requiring literally every possible workflow check without adjustment would be brittle and could block unrelated PRs.

Proposed policy

A PR is not mergeable until every applicable merge-gating CI check has succeeded.

"Applicable" means:

• the check is part of the repo's merge gate for correctness, buildability, security, or release readiness
• the check ran for the PR, or was skipped in a way that still resolves to success

Non-gating automation/advisory jobs do not need to block merge unless we explicitly decide they should.

Proposed initial gating set

Open to trimming, but this is the concrete set I think we should treat as merge-gating unless there is a strong reason not to:

• tests / Test
• tests / Lint
• tests / CLI E2E
• tests / E2E
• tests / Security Scan
• analyze
• malware-scan
• GPU Smoke Test
• GPU Inference Test
• GPU Training Test (if flake rate is acceptable; otherwise fix flakiness first)
• Docker Validator (matrix)
• Docker Manifest
• grype
• ClamAV
• vuln-scan

For CodeQL, if we want findings to block merges, we should use GitHub's dedicated code-scanning merge protection rather than treating it as just another required status check.

Implementation options

Option 1 (preferred): one required aggregate gate

Create a single required merge-gate status check that depends on all gating jobs. For conditionally applicable jobs, use job-level conditionals or a no-op companion job so the aggregate result resolves cleanly on irrelevant PRs.

Pros:

• one stable required check in the ruleset
• new gating jobs can be added behind the aggregate without editing branch protection every time
• avoids most path-filter / pending-check edge cases

Option 2: expand the explicit required check list

Keep using the ruleset's explicit required-status-check list, but expand it to include every check we want to gate merges on. Any workflow-level path-filtered check that becomes required must first be refactored so irrelevant PRs resolve as success rather than pending.

If CodeQL should block merges, we should also enable GitHub's dedicated code-scanning merge protection instead of treating it as advisory only.

Why this matters

• Regressions reach main undetected. A PR that breaks the Docker build or a GPU test can be merged today; the breakage is only discovered later on main, blocking release.
• Security signals are weaker than intended. Some scanners run, but their results do not consistently gate merges today.
• The current required list is a historical snapshot. New workflows added after the ruleset was authored are not required by default.

Scope of change

• Update the ruleset on refs/heads/main (ruleset id 12304487) so merges are blocked on all gating CI checks, not just the current 7.
• Explicitly define which checks are merge-gating.
• Preserve path-filter / conditional behavior by ensuring irrelevant checks resolve successfully rather than staying pending.
• Keep all other ruleset settings (1 approval, CODEOWNERS, signed commits, linear history, squash-only, strict mode) unchanged.

Out of scope

• Flaky-test reduction (handle separately once checks are required).
• Broadening which workflows run on PRs.
• Making every automation or informational check block merges.

Requested action

This needs a repo admin to update ruleset main (id 12304487).

I suggest we first agree on the gating set and then decide whether to implement it via:

• a single aggregate merge-gate check, or
• an expanded explicit required-check list

@mchmarny, could you own this or route it to the right admin?