Repository navigation
e2e: two BATS suites left in hack/e2e-apps/ are not run by anything #3786
Description
Activity
- added a commit that references this issue
on Sep 3, 2026 A second reason to resolve these rather than leave them sitting, found while reworking the OIDC chainsaw suites.
Both files describe themselves as render-side:
monitoring-oidc-system.bats:3says "render-side",:82says "which the render-side test deliberately avoids", andmonitoring-oidc-customconfig.bats:4says "render-side only". That mode is what #3802 removes for the chainsaw OIDC suites. A test that applies a tenantKubernetesCR cannot end at its render-side asserts, because the release is still installing and the remainder gets billed to the cleanup budget on top of the teardown.So these two are not merely unexecuted. They document an approach the tree is moving away from, and being unexecuted is what let that go unnoticed. Whichever way this resolves, wired in or deleted, the render-side framing should not survive it unexamined.
hack/e2e-apps/still holds two BATS suites, and nothing runs them.The three places that could pick them up do not.
BATS_UNIT_FILES := $(filter-out hack/e2e-%.bats,$(wildcard hack/*.bats))is not recursive, somake unit-testsnever sees the subdirectory.hack/select-e2e.shmatcheshack/[^/]+\.bats$, which excludes it by the same shape.packages/core/testing/Makefiledoes run BATS throughhack/cozytest.sh, but only for three files named one by one:e2e-prepare-cluster.bats,e2e-install-cozystack.bats,e2e-test-openapi.bats.This is not an oversight in wiring.
hack/e2e-chainsaw/README.mdsays what happened:Most of that suite was ported, and the ported files carry it in their headers ("Chainsaw port of hack/e2e-apps/bucket.bats", and so on). Two were left behind when the directory stopped being wired up, so they now sit in the tree looking like tests while being dead weight.
What makes it worth an issue rather than a cleanup commit is that the two are not obviously disposable. They cover monitoring OIDC in two shapes, custom config and system, and the Chainsaw tree has no equivalent. So the choice is between porting them and deleting them, and that needs someone who knows whether the coverage is still wanted.
Whichever way it goes, the current state is the worst of the three: a reader grepping for OIDC monitoring coverage finds them and reasonably concludes it exists.
One consequence worth stating because it bit during unrelated work: assertions in these two files are unverifiable by any run, so a defect in them is invisible until someone reads the file. Two of the negated assertions there were rewritten recently and could only be checked by reasoning, not by running anything.