Before proceeding

• I didn't find a similar issue

Problem

values.yaml files can grow complex, especially when using generic charts like this. Imagine you plug this chart 10 times under different chart aliases to deploy 10 applications in the same release. Then there will be a lot of configuration duplicated in values.yaml between these apps.

To keep values.yaml DRY, YAML only has aliases and anchors, but they have way too many limitations, like no deep merge for maps, no cross-file aliases, etc.

Solution (if you have one)

We could allow Go templating in values.yaml. I'm not for it:

1. Too complex.
2. Not valid YAML anymore.
3. I don't want to force users to use Go templates, when they use (not implemented yet) alternative to Go templates for manifests.

Long time ago as a werf user I did _include key support in Helm templates. This worked surprisingly well.

I'm thinking on implementing something like __merge natively in Nelm. This is very simple, but flexible approach, and it will still be valid YAML.

It might look like this. Given:

defaults:
  base:
    ingress: true
    replicas: 1

  backend:
    ingress: false
    resources:
      limits:
        memory: 256Mi
      requests:
        memory: 128Mi

backend1:
  __merge: .defaults.base, .defaults.backend
  replicas: 3

... results in:

backend1:
  ingress: false
  replicas: 3
    resources:
      limits:
        memory: 256Mi
      requests:
        memory: 128Mi

It can have everything that YAML aliases don't have: deep map merge, etc.

All merges will be processed after Helm compiles the one merged values tree. Validation with values.schema.json might be affected, but we might just forcefully do additionalProperties: true everywhere.

Additional information

No response