testscan

Overview ¶

testscan reports every repository whose CI runs `go test` on only part of what has tests — or on nothing at all.

testscan                  # the whole fleet, under the GitHub root
testscan -root DIR        # somewhere else
testscan -repo o/r        # one repository, verbosely
testscan -all             # include the repositories that are fine

It exists because of openweft/weft. Five workflows, `go test` in exactly one of them, naming four packages with -tags=integration. 83 packages have tests. The other 79 had never run in CI, and nothing said so: every lane was green, because every lane was green about the four.

Switching on a plain `go test ./...` there found two tests that could not pass on Linux at all — one asserting the host's own hypervisor, one racing for a TCP port. Both had been waiting since the packages were written.

What it looks at, and what it cannot see ¶

It reads the working tree: which directories hold _test.go files, and which `go test` invocations appear in .github/workflows. An invocation naming `./...` is taken to cover everything; one naming paths covers those paths.

Three things it cannot resolve, each reported rather than guessed:

• `go test` inside a script the workflow calls (run: bash scripts/ci.sh). The call is visible, the contents are not; such a repository is marked "defers to a script" and left for a human.
• Build tags. `go test ./...` does not compile files behind `//go:build integration`, so a repo can cover every package and still not run those tests. Noted in the output when tagged test files exist.
• A `-run` filter, which narrows what executes inside a package that IS named. go-widgets/window's lanes each name one test; that turned out to be fine (prefix matching covered all 19), but only counting said so.

It reads the working tree only. The SCAN makes no API calls, so it cannot starve Renovate — but each FINDING is confirmed with one, because a checkout on disk is not necessarily one of our repositories. Six of nineteen findings on 2026-09-27 were forks, a local-only directory, or upstream's own project; telling somebody hashicorp/hcl has no CI is worse than saying nothing. That is nineteen calls, not nine hundred and twenty-five, and an unanswered question keeps the finding.