ci: fail-closed when ops-scripts unittest collects 0 tests #2448
Reference in New Issue
Block a user
Delete Branch "fix/ci-fail-on-zero-tests-collected"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Gate-integrity: fail-closed when an ops-scripts unittest pass collects 0 tests
The bug (green-but-empty)
.gitea/workflows/test-ops-scripts.yml, step "Run scripts/ unittests, if any", detected "no tests collected" with:But Python 3.12's
unittestexits0(not5) when discovery finds 0 tests:So the
rc==5guard never fired. The step passed GREEN while running ZERO tests — meaning anytest_*.pyadded underscripts/would have been silently never executed. A green job that runs 0 tests is worse than a red one.The fix (fail-closed)
scripts/(top-level) step — count viaTestLoader().discover(...).countTestCases(), not exit code:test_*.pypresent → loud SKIP (legitimate no-op today — the runtime-packaging tests moved tomolecule-ai-workspace-runtime, so there are none)test_*.pypresent but 0 collected → FAIL (broken import / empty / discovery error)scripts/ops/step (real gate, 34 tests today) — assert >0 collected so deleting all test files or breaking an import can't pass green by running 0 tests.ci.yml"Diagnostic — per-package verbose 60s" — this iscontinue-on-error: trueand explicitly advisory (the blocking gate is the next step, "Run tests with coverage (blocking gate)"). Left functionally unchanged; only a clarifying comment added so itsset +eisn't mistaken for the same bug class. It is intentionally not made gating.The real
Ops Scripts Testspytest gate (.gitea/scripts/tests, 362 tests) is untouched.Proof (run on operator)
scripts/unittest exits 0 on 0 tests → the bug, confirmedopsguard: PASS at 34, FAIL on empty dirPart of a gate-integrity hardening pass.
🤖 Generated with Claude Code
Gate-integrity hardening. The "Run scripts/ unittests, if any" step in .gitea/workflows/test-ops-scripts.yml detected "no tests collected" via `rc=$?; if [ "$rc" -eq 5 ]`. But Python 3.12's unittest exits 0 (not 5) when discovery finds 0 tests ("Ran 0 tests ... NO TESTS RAN"), so the guard never fired: the step passed GREEN while running ZERO tests. Any test_*.py added under scripts/ would have been silently never executed. A green job that runs 0 tests is worse than a red one. This fails closed: scripts/ (top-level) step: - genuinely NO test_*.py present -> loud SKIP (legitimate no-op; the runtime-packaging tests moved to molecule-ai-workspace-runtime, so there are none today) - test_*.py present but 0 collected -> FAIL (broken import / empty / discovery error) Count is via TestLoader().discover(...).countTestCases(), not exit code. scripts/ops/ step (real gate, 34 tests today): - assert >0 collected so deleting all test files or breaking an import can't pass GREEN by running 0 tests. ci.yml "Diagnostic — per-package verbose 60s" is continue-on-error and explicitly advisory (the blocking gate is the next step); left functional unchanged, only a clarifying comment added so its `set +e` isn't mistaken for this same bug class. The real `Ops Scripts Tests` pytest gate (.gitea/scripts/tests) is untouched. Proven on the operator: scripts/ unittest exits 0 on 0 tests (the bug); new guard SKIPs on no-files, FAILs on files-present-but-0-collected, PASSes on a real test; ops guard PASSes at 34 and FAILs on empty. Workflow-YAML linter green (0 warnings). Part of a gate-integrity hardening pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>APPROVED on current head
f1ccd3bb05.5-axis/gate-change review: this is a scoped fail-closed improvement to ops-script unittest collection. The top-level scripts step now distinguishes a genuine no-op (no test_*.py files present) from a broken/empty discovery result (test files present but 0 collected), and scripts/ops now asserts >0 collected before running discovery. Import errors still fail through the actual unittest run, so this does not create a new bypass.
No gate weakening observed: CI/all-required remains green, Ops Scripts Tests is green, trusted SOP checklist is green, and the change only documents an existing diagnostic continue-on-error step while leaving the blocking coverage gate immediately below it intact. Security/content-security pass found no secrets, credentials, tokens, hostnames, internal paths, provisioning mechanics, or sensitive env/image markers added. Scope is limited to workflow comments and ops-script test execution guards.
Live statuses checked: CI/all-required, E2E API Smoke, Ops Scripts Tests, secret scan, lint-required-no-paths, gate-check-v3, and trusted sop-checklist pull_request_target are green. Local Provision rows are advisory/non-required. No merge performed.
Security-team-21 review on current head
f1ccd3bb. Rechecked corrected pull_request required runs: E2E API Smoke job 391130/run 293072 success and Handlers Postgres job 391136/run 293075 success; CI/all-required and Ops Scripts Tests green; trusted SOP target row is green. Prior review found the ops-script unittest collection change gate-strengthening/fail-closed: no-files top-level scripts remains explicit skip, present test_*.py with 0 collected fails, and scripts/ops requires >0 collected. No qa/security/sop/required-CI weakening and no content-security issue found.Security-team-21 review on current head
f1ccd3bb. Rechecked corrected pull_request required runs: E2E API Smoke job 391130/run 293072 success and Handlers Postgres job 391136/run 293075 success; CI/all-required and Ops Scripts Tests green; trusted SOP target row is green. Prior review found the ops-script unittest collection change gate-strengthening/fail-closed: no-files top-level scripts remains explicit skip, present test_*.py with 0 collected fails, and scripts/ops requires >0 collected. No qa/security/sop/required-CI weakening and no content-security issue found.