ci: make the EoSim Sanity Gate fail on any dependency, and give it nothing to close on

[Kartikey1306]

Closes #150

Two fixes, one change, because the first is unmergeable without the second. sanity-gate was fail-open — five needs, one checked — and the two jobs it hid, Windows Sanity and macOS Sanity, still install eosim from a release wheel URL that 404s. A fail-closed gate is only mergeable when there is nothing to close on, so the gate fix and the wheel fix land together. The wheel hunks are srpatcha's #121, carried verbatim; the two PRs merge in either order, and if #121 lands first this reduces to the gate. Evidence that the gate works came from this branch's own earlier heads, where it went red naming both jobs on the identical state master's gate had passed (runs 35204716639, 35207728484).

Stacked on #132 (4054494) — review 4054494..99e5dbd for this change: one commit, two files (.github/workflows/eosim-sanity.yml, tests/unit/test_ci_gate.py). Land #132 first. (Previous heads: bad8cb7 off master — inherited master's mypy break on every Test leg, which #132 repairs; 9866819 on #132 — gate only, red by design. This head adds the wheel fix.)

Problem

sanity-gate needs: five jobs, prints all five results, exits non-zero only when install-validate is not success, and otherwise prints ✅ All EoSim sanity checks passed.

Observed on master, not inferred: run 35181688794 (2026-09-17 04:22Z) — Windows Sanity failure, macOS Sanity failure, EoSim Sanity Gate success. Same on 09-16. The gate is the one job in this workflow a required-check policy would name, and it has been asserting more than it checked.

Change

Gate. The body iterates toJSON(needs) — the gate eos and eBoot already run — so it cannot fall out of step with needs:, and it fails on any result that is not success (including skipped) and on an empty/null payload, which is not "no failures". needs:, if: always() and the job list are unchanged. The workflow is added to its own pull_request: paths: filter so a change to it gets the run that proves it; it was schedule- and dispatch-only.

Wheel. windows-sanity and macos-sanity gain an Install EoSim from source step — git clone --depth 1 --branch v${{ env.EOSIM_VERSION }} … /tmp/EoSim && pip install -e /tmp/EoSim, the path install-validate already runs green on windows-latest and macos-latest with the same eosim list && eosim doctor after it — and the pip install "eosim @ …/eosim-1.5.0-py3-none-any.whl" line is removed. No EoSim release has ever shipped a wheel (memory of 09-01; both jobs 404 on every run). Byte-identical to #121's hunks; no wheel URL remains anywhere in the file.

Verification

Both gate bodies executed locally with this morning's needs values (install-validate success, both sanity jobs failure, the rest success):

old body                     -> rc=0  "✅ All EoSim sanity checks passed"
new body                     -> rc=1  "These jobs did not succeed:
                                          windows-sanity: failure
                                          macos-sanity: failure"
new body, one job skipped    -> rc=1
new body, RESULTS empty      -> rc=1  "gate received no results to check"
new body, RESULTS null       -> rc=1
new body, all five success   -> rc=0

Parsed structure asserted on the document, not on parse success: needs still the same five, if: always(), six jobs in the same order, needs.install-validate.result no longer referenced anywhere in the step, pull_request.paths == ['.github/workflows/eosim-sanity.yml'], schedule and workflow_dispatch retained.

This head 99e5dbd — run 35208305579: all 22 jobs succeed — 9/9 Install & Validate, 7/7 Nested Simulation, 3/3 Guest OS Install, Windows Sanity ✅, macOS Sanity ✅, and EoSim Sanity Gate ✅ with All EoSim sanity jobs succeeded. — 52 checks pass on the PR, 0 fail. Of the 100 EoSim Sanity runs in this repository's history, this is the second success and the first under a gate that could have failed: the other is #121's workflow_dispatch run 35035512098 on 09-15, whose sanity jobs also passed on the same clone path but whose gate was the fail-open one.

Earlier heads' EoSim Sanity runs — the gate proving itself by going red. Run 35204716639 at bad8cb7: 9/9 Install & Validate ✅, 7/7 Nested Simulation ✅, 3/3 Guest OS Install ✅, Windows Sanity ❌, macOS Sanity ❌ (the 404 wheel, #121's defect, unchanged here), and EoSim Sanity Gate ❌ with:

##[error]EoSim Sanity Gate failed. These jobs did not succeed:
  windows-sanity: failure
  macos-sanity: failure

Master's gate reported success on the identical five results at 04:22Z the same day (run 35181688794). The red on this PR is the gate working. Anything the path filter does not trigger is NOT RUN here.

On the restacked head 9866819 — run 35207728484: the same three — Windows Sanity ❌, macOS Sanity ❌, EoSim Sanity Gate ❌ naming both — and nothing else red: CI Gate ✅ and all nine Test (Python 3.10/3.11/3.12 × macos/ubuntu/windows) legs ✅, which at bad8cb7 off master were red on master's mypy break. 49 checks pass; the 3 that fail are the finding.

The registry entry

Adding the pull_request trigger makes this a pull-request workflow in tests/unit/test_ci_gate.py's eyes, and that registry requires every such workflow to be either required (with its gate) or excused with a reason about the workflow itself — otherwise test_every_pull_request_workflow_is_accounted_for fails, which it did at bad8cb7. It is recorded as not requirable: the trigger is filtered to this one file, so on a pull request touching nothing else it reports no status, and a required check that never arrives hangs the merge rather than failing it — the reason eos records its book-build.yml the same way. The gate is fail-closed for the runs it does make. Negative control: with the entry removed the test fails again (1 failed, 10 passed); with it, 11 passed; full pytest 683 passed / 1 skipped; ruff clean.

Scope

The gate, the two wheel hunks (srpatcha's #121, verbatim), and the registry entry. Nothing else in the workflow is changed.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!