🐛 fix(olm): give every owned CRD an alm-examples entry

[konih]

Why

The upstream OperatorHub hosted validator warns provided API should have an example annotation for every owned CRD that has no entry in metadata.annotations["alm-examples"]. Nine of the eleven owned kinds had none, so the OpenShift console and operatorhub.io "Create instance" flow handed users a blank YAML editor for all nine.

What changed

All 11 owned CRDs now carry an alm-examples entry in config/olm/template/manifests/kollect.clusterserviceversion.yaml:

KollectClusterInventory, KollectClusterScope, KollectClusterTarget, KollectConnectionTest, KollectDatabaseSink, KollectEventSink, KollectInventory, KollectProfile, KollectScope, KollectSnapshotSink, KollectTarget.

Every example was validated two ways:

• server-side dry-run against a kind cluster with --validate=strict, so no field is misspelled or unknown to the CRD schema;
• against the operator's own Go spec validators, so the examples are semantically valid input, not merely schema-shaped.

The assertions this replaces were vacuous

hack/test/dist_olm_bundle_test.sh previously asserted alm-examples coverage with two greps:

grep -Fq 'kind: KollectProfile' "${csv}"
grep -Fq 'kind: KollectTarget'  "${csv}"

Both search for the unquoted kind: KollectProfile form, which only ever matched the plain-YAML spec.customresourcedefinitions.owned list (line 349 of the CSV) — never the JSON inside the annotation, where the kind appears as "kind": "KollectProfile". Deleting the entire alm-examples annotation left both greps passing. They never tested alm-examples at all.

They are replaced by a set-comparison gate (check_alm_examples) that:

• extracts the kind set from the alm-examples JSON and the kind set from spec.customresourcedefinitions.owned, and requires them to be equal — so a newly owned CRD cannot ship without an example;
• asserts both extracted sets are non-empty, so a mistyped yq/jq path fails loudly instead of comparing two empty sets and passing vacuously;
• rejects duplicate kinds, so a repeated entry cannot mask a missing one;
• checks the annotation is valid JSON and is a JSON array;
• runs against both the template (the file an author edits) and the generated bundle CSV (what upstream actually validates) — generation is a sed pass, so a template-only assertion would not prove the annotation survives it.

jq is now asserted as a hard requirement alongside yq, so a missing tool fails the gate rather than silently skipping it.

Verification

The independent reviewer confirmed the new gate is non-vacuous with 10 perturbations plus a positive control — removing the annotation, emptying it, corrupting the JSON, duplicating a kind, dropping a single kind, and breaking each extraction path all fail the gate; the unmodified tree passes.

Local gate matrix on the rebased head: all hack/test/dist_*.sh, task verify, task lint, task test, and pre-commit green. A DRY_RUN=1 bundle generation produces a CSV whose alm-examples contains exactly 11 entries, 11 distinct kinds, matching the 11 owned CRDs exactly.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud