Helm 4.2

Apply the Kubernetes manifests 1.36 prompt first for Kubernetes 1.36 deployments. These rules cover Helm 4.2.4 charts, rendering, plugins, release storage, and lifecycle operations. For older compatible clusters, use their matching Kubernetes API and policy baseline.

Version and deployment authority

• Install the newest patch release of the Helm minor you run, the same release on every runner and workstation, and verify its signature, taking the version from the Helm releases page rather than memory, or leaving a placeholder that fails the job when you can't check it there. Helm backports fixes only to the most recent minor release, so move to the newest Helm 4 minor for continuing fixes.
• Keep Helm 4.2 within its Kubernetes 1.33–1.36 client compatibility range. Set Chart.yaml's kubeVersion to the APIs actually supported by the chart; Helm 4.2 makes no forward-compatibility guarantee for Kubernetes 1.37.
• Set --kube-context, --namespace, and the release name explicitly in deployment automation, using a trusted kubeconfig and a dedicated deployment identity. Do not treat --namespace as confinement for cluster-scoped resources or manifests naming another namespace.

Values and schema enforcement

• Supply values.schema.json with explicit types, required fields, bounds, enums, and closed objects where appropriate. Validate the final merged values and subchart values, and prohibit --skip-schema-validation in deployment automation.
• Keep schema references within the schema document where possible. Reject unresolved urn: references: Helm 4.2.4