test(e2e): hold the tenant-cluster install wait to an ordering rule - #3802

20m here against timeout-minutes: 180 on the e2e job, and this PR's own run was 172m39s, so headroom is 7m21s. On a real install failure this assert reaches its ceiling every time because the release retries forever, and crossing the job cap loses cozyreport.tgz and the log both. Either land #3754 first so the headroom exists, or take the per Test timeouts: {cleanup: 10m} lever you already considered and rejected, which costs nothing on either path and lets this drop to 8-10m without reding a legitimately slow install. Do not just lower the number on its own, the 15m floor from bootstrap-token-tenant-job.yaml:41-48 is real.

The 180 moved after you wrote this. ad62a8d62 raised the e2e job to timeout-minutes: 215 on 2026-08-20, and .chainsaw.yaml in the same directory already says 215, so the headroom against that 172m39s run is about 42m rather than 7m21s. My own fixtures were still arguing against 180 in four places, which is the real defect you caught, and it is fixed.

The derivation you were reading was also wrong, in a way the number happened to survive. It built the floor on bootstrap-token-tenant's backoffLimit: 10, but that Job carries no helm.sh/hook annotation at all. It is a main-phase resource, helm-controller never waits on it, and its retry ladder cannot hold the Ready condition open. The chart's only blocking post-install hook is oidc-bootstrap in oidc-rbac-job.yaml.

So the budget is fixed by its ceiling rather than by headroom: the kind sets release.cozystack.io/helm-install-timeout: "20m", and past that helm-controller abandons the install attempt, so a longer wait spends the difference watching an attempt already given up on. The floor is that hook's own 600s kubeconfig deadline under backoffLimit: 6. The interval is (10m, 20m] and 20m is the top of it, equal to the point where success stops being observable.

That is also why I did not take it to 8-10m: it sits below the floor, though for a different reason than the fixture used to give.

timeouts: {cleanup: 10m} I agree costs nothing on a passing run, and it is going in as its own change. Both observations of this teardown are censored at 300s, so any value today would be picked rather than measured; #3801 is where it gets measured.

One thing worth flagging since it is not visible from the diff: both suites now carry 20m, not just this one. The floor and ceiling are properties of the chart and identical for any suite installing this kind, so the asymmetry you would have seen in an earlier revision is gone.

Glob is *.yaml here and */chainsaw-test.yaml at 258, so a fixture named .yml or sitting one directory deeper is invisible to discovery and every test stays green. I checked both, renamed a fixture to .yml and nested another one with no asserts at all, six tests green in both cases. The doc says "two shapes are outside the guard's reach", which reads as the full list. *.y*ml and either recursion or a stated flat directory assumption.

Both holes confirmed and fixed. I reproduced each before changing anything: renaming kubernetes-oidc-system.yaml to .yml dropped that suite out of discovery entirely with all six tests still green, and moving the suite one directory deeper did the same.

One enumerator now serves both directions of the walk: find under the suite directory, paths relative to it, both YAML spellings, plus an ownership helper so a nested suite keeps its own manifests. Recursion rather than a documented flat-directory assumption, because Chainsaw walks the tree itself and an assumption written in a comment does not fail when someone breaks it.

Your repro also exposed a third hole underneath the two. With the walk widened, a walk returning nothing still left every rule iterating an empty list and passing. Every consumer now goes through _require_tenant_cluster_tests, which refuses an empty or failed walk.

And a fourth, which your framing predicted without naming it: an apply.file pointing into a subdirectory escaped both directions at once, because the reverse walk enumerates through the same helper. Fixed by the same enumerator and pinned by its own mutation case.

The doc sentence you flagged was right to flag. It now says the shapes are the ones someone noticed rather than a closed list, because a subdirectory apply.file belonged on that list and nobody had noticed.

Confirmed this one is live and not theoretical: wrote the assertion inline above the wait instead of calling a cozy_assert_* helper, guard stays green. Header says so and doc bullet 9 says so, so not asking to change it, rule holds naming convention and that is what it can hold.