test(e2e): a seaweedfs change escalates to the full suite because its source maps to a suite that does not exist #4283

Describe the bug

hack/select-e2e.sh maps the PackageSource cozystack.seaweedfs-application to a suite named seaweedfs. No such suite exists, so the path resolves to nothing runnable and the selector escalates:

$ echo packages/system/seaweedfs/values.yaml > /tmp/f && sh hack/select-e2e.sh /tmp/f
select-e2e: no runnable suite covers cozystack.seaweedfs-application — escalating to the full suite
bucket clickhouse etcd external-dns foundationdb gateway harbor kafka ...

The suite that does exercise seaweedfs is bucket: it creates Buckets against the tenant-root instance and writes to them through the S3 gateway.

So every change under packages/system/seaweedfs or packages/extra/seaweedfs pays a full 23-suite run to exercise one suite. The escalation is the selector behaving as designed for an uncovered path, so this is cost rather than a correctness hole, but it is cost on every seaweedfs pull request.

Why it is not a one-line mapping

src_to_suites() has to round-trip through suite_to_source() in select-install.sh, and hack/select-e2e_test.bats walks every suite through both tables, so a name that does not round-trip fails there rather than quietly making its own suite unreachable. bucket is already the image of bucket-application, so pointing seaweedfs-application at bucket as well makes the mapping non-injective, which is exactly what the round-trip test is checking. Anyone who tries the obvious rename hits a red test without the reason being visible from the diff, which is why it is written down here.

There is prior art for a source owning more than one suite (kafka-application maps to kafka kafka-metadata), but not yet for two sources sharing one suite, which is the shape this needs.

Environment

• Cozystack: main at 070dcb1e3
• Applies to the in-tree and fork e2e lanes equally, since both run the same selector

To Reproduce

echo packages/system/seaweedfs/values.yaml > /tmp/f
sh hack/select-e2e.sh /tmp/f

Expected behaviour

A seaweedfs-only change selects the suite that covers seaweedfs.

Actual behaviour

It selects all of them, and prints the escalation reason on stderr.

Additional context

Found while reviewing a seaweedfs change; the escalation is visible in that pull request's own selector output. The same escalation fires for an edit to hack/e2e-chainsaw/.chainsaw.yaml, since shared e2e material escalates by a separate rule, so a change touching both pays it once either way.

Checklist

• I have checked the documentation
• I have searched for similar issues
• I have included all required information
• I have provided clear steps to reproduce
• I have included relevant logs