Two suites sat in hack/e2e-apps/ for three weeks without executing
once, and nothing in the tree could notice: the property "something
runs this file" was described in prose in three comments and asserted
nowhere. This adds the assertion.
There are exactly two runners and that is a closed list by design --
the root Makefile's one-level, non-e2e glob, and the literal suite
names in packages/core/testing/Makefile. A file matching neither is
reported, as is the inverse: a name in the e2e Makefile with no file
on disk, which today surfaces forty minutes into the e2e job, or wedges
the bootstrap outright. A suite named through a make variable, the
shape of the rule #2826 deleted, is reported as unresolvable rather
than expanded, because a pattern rule nobody invokes is as dead as no
rule.
The Makefiles are parsed rather than asked. hack/common-envs.mk is
included at Makefile:3 and runs `git remote add upstream` and `git
fetch upstream --tags` in $(shell ...) at parse time, so `make -p` or
`make -n` would have a unit test mutate git remotes and reach the
network to answer a question about filenames. The cost is that the
model can drift from what it models, so a second test pins the modelled
lines verbatim -- that is the one direction which would otherwise widen
the covered set in silence.
No allowlist, deliberately: the off-switch is the .disabled suffix,
which the scan stops seeing on its own. An in-test list of exempt paths
would be the same artefact class as the runner that got deleted while
its documentation stayed.
That documentation is corrected here too. Makefile's comment claimed a
new .bats file in hack/ is picked up automatically, which holds only at
the top level and is the false claim this bug grew in.
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Myasnikov Daniil
3fbbcd1537