run-tests-uv: `testpaths` silently overrides `root-dir` — package doctests never run, CI stays green

[thorwhalen]

Summary

[tool.pytest.ini_options] testpaths silently overrides the root-dir input of the run-tests-uv action. In a repo with testpaths = ["tests"], the package's own doctests execute nowhere — not locally, not in CI — while CI reports green.

Why this is easy to miss

run-tests-uv invokes pytest with --doctest-modules but no path argument. Collection is therefore driven entirely by testpaths. The action's root-dir input only feeds --cov=, so it looks like the package dir is being collected when it is not. Coverage numbers can even look plausible because --cov still names the package.

Unlike ruff-ruleset drift, this failure mode does not turn a repo red. It keeps it green while testing nothing, so it is invisible until someone widens testpaths and watches the collected-item count jump.

Observed impact

Found in 3 of 8 repos in a single wave-0 rollout batch:

repo	before	after widening testpaths
i2mint/focal	1 item collected	7 — focal/tests/test_extension_store.py plus all module doctests had never run
i2mint/dol_cookbook	pipes.py 0% covered	100%
i2mint/reci	testpaths pointed at a tests/ dir that does not exist → silent pytest rootdir fallback

i2mint/doodad still has 3 latent doctest failures hidden this way (see i2mint/doodad), and i2mint/ij has 2 broken doctests plus one that hangs indefinitely (see i2mint/ij).

Proposed fix

Options, roughly in order of preference:

1. Make run-tests-uv pass an explicit path (the package dir) rather than relying on testpaths, so the action's contract matches its documented behaviour.
2. Have read-ci-config warn loudly when testpaths is set and excludes the package directory, so the repo owner sees it in the CI log.
3. Add a wads audit check: "package contains >>> doctests but testpaths omits the package dir" → surface as a repo_audit finding.

⚠️ Hazard for any fleet-wide sweep

Do not naively widen testpaths across the fleet. At least one repo (i2mint/ij) has a package doctest that hangs indefinitely — pytest <pkg> --doctest-modules never terminates. Any sweep needs a per-repo timeout and a way to quarantine hangers.

Reproduce

In an affected repo:

python -m pytest --collect-only -q                                  # what CI actually collects
python -m pytest <pkgdir> --doctest-modules --collect-only -q       # what you assumed it collects

Surfaced during the 2026-07-30 wave-0 rollout batch. Cross-ref: the running sweep journal in #51.

[thorwhalen]

Triage / plan

Confirmed the mechanism against `actions/run-tests-uv/action.yml` and `wads/ci_config.py`: `run-tests-uv` invokes `pytest --doctest-modules` with no explicit path, so `[tool.pytest.ini_options].testpaths` (when it excludes the package dir) silently drives collection to `tests/` only, while `root-dir` only feeds `--cov=`.

Not fixing directly — this is exactly the "breaking change whose dependents I can't check" case from the crowsnest decision rule. `run-tests-uv` is consumed by every wads-managed repo through the reusable workflow (uv-ci.yml); making it collect doctests it currently skips would, for at least one confirmed repo (i2mint/ij), turn a currently-green CI run into a job that hangs indefinitely (per this issue's own reproduction), and for others (i2mint/doodad) surface latent doctest failures. I can't enumerate or gate on that fleet-wide blast radius from here.

Recommended shape, in the order the issue itself proposes:

1. Do not silently widen collection fleet-wide in one shot — that's the hazard this issue explicitly calls out.
2. Land the warning first (option 2: read-ci-config warns loudly when testpaths is set and excludes the package dir) — purely additive, never reddens a currently-green run, surfaces every affected repo's CI log without forcing a fix.
3. Only after that visibility lands and repos have had a chance to react, consider making run-tests-uv pass an explicit package path (option 1) — and even then, per-repo, not as a single reusable-workflow flip, with a documented per-repo opt-in/timeout (the ij hang needs a pytest-timeout or explicit quarantine before that repo can survive real doctest collection).
4. A repo_audit finding (option 3) is the cheapest of the three and could ship alongside the warning.

This needs your sign-off on the rollout shape (warn-only first vs. accept-some-repos-go-red) before any of it lands — filing as `manual-task`. The running sweep journal in #51 is a place to log rollout progress once you pick a path.

[thorwhalen]

Cloud sweep (PR #99): fixed for wads itself; the fleet-wide part stays open and is labelled needs-local.

What wads's own CI was missing: with testpaths = ["wads/tests"], none of the package's 73 doctests ran, and two of them had drifted into failing (whitespace only, because run-tests-uv's -o doctest_optionflags=... replaces the repo's NORMALIZE_WHITESPACE). The PR sets testpaths = ["wads"], adds a root conftest.py with collect_ignore = ["wads/data"] (templates like test_smoke_tpl.py are not valid Python), fixes the two doctests, and pins the scope with wads/tests/test_collection_scope.py. Widening also exposed a test-isolation bug on Python 3.10 (a sys.modules leak in test_light_install.py broke mock.patch), fixed in the same commit.

Two lessons for the fleet rollout:

• Widening collection surfaces flag-sensitive doctests: the action's -o doctest_optionflags override drops a repo's own NORMALIZE_WHITESPACE. Consider having run-tests-uv append the repo's flags instead of replacing them.
• Test-order bugs appear once package modules are imported during collection, so run the widened suite on every matrix Python before flipping a repo.

The fleet-wide change (option 1 or the warning in option 2) still needs your decision on the rollout shape, and verifying it needs fleet CI runs, which the cloud VM can't do.

---

Generated by Claude Code