Bind the controller chart to CWE

The Definition says which image the chart uses:

outputs:
  - name: controller-chart
    components: [controller-chart]
    format: helm-oci
    platform: linux/amd64
    helm:
      images:
        controller: cwe
  - name: cwe
    components: [cwe]
    format: oci
    platform: linux/amd64

Read controller: cwe as “use the cwe output for this chart’s controller image.” To bind another image, add another slot-to-output entry. NVKR derives the build dependencies.

The catalog producer maps the slot to the existing value:

helm:
  chart: .
  images:
    controller:
      values:
        digest: image.digest

NVKR writes the verified CWE image digest to image.digest. For root charts, upstream checksum files are preserved; nested wrappers refresh binder-owned checksums outside the chart. Templates, repository and tag defaults stay unchanged. Values are reserialized with the YAML library: formatting can change, and document-level comments separated from the root mapping may be omitted. Template bytes stay unchanged. Unknown or unbound slots and missing or ambiguous value paths fail.

For a source template that already adds sha256:, declare values.digestFormat: sha256-hex beside values.digest. NVKR still authenticates the complete image manifest digest, but writes only its hex to that value. Omission preserves the full sha256:<hex> representation. Unknown formats fail closed; templates stay upstream-owned. The OVN output example uses this mapping for its six enabled image slots.

Registry choice

The installer supplies the repository holding that image:

helm template controller ./controller --set-string image.repository=registry.operator-a.test/nvke/cwe
helm template controller ./controller --set-string image.repository=mirror.operator-b.test/platform/cwe

Both use identical chart bytes and the packaged image digest. The operator must make that image available at the supplied repository. Normal Helm overrides still apply: overriding image.digest changes the selected image. NVKR does not enforce deployment values.

Shared paths

Catalog pin sets and chart mappings use the same path reader:

Missing fields and ambiguous matches fail. Pin sets also reject unaccounted list members.

Concrete NVKE example

Definition and catalog select six outputs: CWE, its source controller chart, SPIRE, SPIRE CRDs, Temporal and PostgreSQL. They share the pinned NVKE controller source; external charts remain acquired and byte-preserving. The controller source archive contains only its chart.

On an AMD64 Linux Docker host, with NVKE source access:

mkdir -p .nvkr/controller-bindings
cp docs/examples/nvke-controller-bindings/*.yaml .nvkr/controller-bindings/
go run ./cmd/nvkr catalog pin --dir .nvkr/controller-bindings \
  --tag controller/v0.1.1-rc.9 nvke-controller
go run ./cmd/nvkr run local \
  --definition .nvkr/controller-bindings/definition.yaml \
  --environment .nvkr/controller-bindings/environment-local.yaml \
  --attempt controller-bindings-01 --runner-source .

The example was pinned against real upstream chart repositories and compiled successfully; its six-output plan makes package/controller-chart depend on package/cwe. This is not a recorded full six-output build. No new image build, signed publication, installation or qualification is claimed. Acquired raw-chart dependency scanning remains unsupported.

Validation and migration

The compiler contracts and binding tests cover slot accounting, unchanged templates, multiple images and registry-independent package bytes. Real Helm rendering is opt-in; see Development for prerequisites and commands. These tests do not establish a full six-output build, installation or signed publication.

Replace helm.imageOutput with helm.images: {controller: cwe}. Put the chart location and digest paths under the selected catalog component’s helm field, then regenerate plans and workflows.