chore(helm): establish Helm chart test and CI infrastructure #4275

Overview

The charts/tekton-operator Helm chart ships to end users via GitHub Releases and OCI (ghcr.io/tektoncd/operator/charts), but it has zero automated testing today — no lint, no template assertions, no install check, no values validation.

This issue tracks the work needed to close that gap. It is also meant to feed a community discussion about possibly moving the chart into its own repository (see #3977).

Current state

The only Helm-related automation today is chart packaging + OCI push on release tags. Any breakage — bad template syntax, wrong env name, wrong image refs — is discovered by a user, not by CI.

Proposed test layers

Ordered by value/cost ratio.

1. helm lint on every PR

Run helm lint --strict on the chart as part of the PR check workflow. Requires no new tooling — Helm is already installed in CI.

Catches: template syntax errors, missing required Chart.yaml fields, YAML validity.

2. helm template smoke assertions

Run helm template with representative value overrides and assert the rendered YAML output using a shell script. No cluster required.

The script should cover:

• Default values — no unexpected env vars injected
• Optional features enabled — e.g. registry set, verify the env is injected exactly once and pod images are rewritten correctly
• Conflict avoidance — e.g. if a user already provides TEKTON_REGISTRY_OVERRIDE in additionalEnvs, Helm must not inject a duplicate
• OpenShift flavour — openshift.enabled: true produces the correct RBAC and image names

3. Deployment topology files + ct install on kind

Create a ci/ directory inside the chart with one values file per supported deployment topology. Each file represents a real-world install shape. A CI job installs the chart with each file on a kind cluster, waits for pods to be Ready, and uninstalls — confirming the chart is functional end-to-end, not just syntactically valid.

Suggested topologies:

Every PR that adds or changes a chart value must add or update the matching topology file so the install test exercises the new behaviour.

ct (helm/chart-testing) is the standard CLI for this pattern. It adds stricter linting (Chart.yaml schema, maintainer validation, YAML style) and drives the install loop automatically from the ci/ files.

4. Unit tests for template helpers (optional)

For charts with non-trivial helper logic (e.g. image registry rewriting, env injection), a unit test framework like helm-unittest allows asserting specific rendered fields without a cluster. Requires a new plugin dependency. Lower priority than 1–3 for a single chart.

Suggested phasing

Future: dedicated chart repository

See #3977. Moving the chart to its own repository would allow independent release cadence, per-chart changelogs, and a dedicated CI pipeline — without coupling every chart change to the Go operator release process.