Closed gbonnefille closed 1 year ago
ValuesContent is just a flat text field that's dumped into a ConfigMap and mounted into the job pod as a file. The HelmChart and HelmChartConfig resource namespaces and names must match for the config to be found, and we're not planning on changing that or allowing for multiple ordered content blocks. My advice would probably be to handle merging the values YAML prior to writing it into the HelmChartConfig resource?
OK, thanks for the answer.
I'm trying to build a reusable set of Kustomization based on HelmChart+HelmChartConfig. In order to allow a design with some overlay for predefined values and other overlays to specify the specific values of a deployment context, I have relative success playing with
set:
and inlining values and one finalvaluesContent:
. But when the application is complex enough, I do not have other option to use thevaluesContent:
for generic part of the configuration. And so, I have no more space to bring specific part of the configuration for a given target.Helm support many values file. Would it be possible to have helm-controller being able to detect and use many HelmChartConfig for a given HelmChart? Or something related to #173 offering the ability to pass a list/struct in
valuesContent:
. This way, it would be possible to prepare a first element in the generic overlay and then merge more element via Kustomisationpatches:
or Component.