helm override variables are limited to strings

[Michael-Kruggel]

Steps to reproduce

1. Add helm override variable to component
2. Set that variable to something other than a string (e.g an array) in the zarf config
3. Deploy package using said config

Expected result

Value of variable is set in chart values

Actual Result

No value is set, chart's default value is used

Visual Proof (screenshots, videos, text, etc)

Example zarf.yaml component:

components:
  - name: jenkins
    required: true
    charts:
      - name: jenkins
        namespace: jenkins
        url: https://charts.jenkins.io
        version: 5.4.3
        repoName: jenkins
        releaseName: jenkins
        valuesFiles:
          - ../values/common.yaml
        variables:
          - name: JENKINS_PLUGINS
            description: "List of plugins to install on Jenkins startup"
            path: controller.installPlugins

Example zarf-config.yaml:

package:
  deploy:
    components: 'jenkins'
    set:
      jenkins_plugins:
        - kubernetes:4238.v41b_3ef14a_5d8
        - workflow-aggregator:596.v8c21c963d92d
        - git:5.2.2
        - configuration-as-code:1810.v9b_c30a_249a_4c
        - oic-auth:4.269.va_7526f34f306
        - prometheus:773.v3b_62d8178eec
        - cloudbees-disk-usage-simple:203.v3f46a_7462b_1a_
        - saml:4.464.vea_cb_75d7f5e0

Values in k9s:

[Racer159]

This is relatively simple to accomplish internally to Zarf by changing string to interface{} on the SetVariables field however the wall this is effectively blocked on (https://github.com/spf13/viper/issues/1014) would need a workaround like what UDS CLI has done: https://github.com/defenseunicorns/uds-cli/blob/main/src/cmd/root.go#L151 (which as-written there only supports YAML) or would need to swap around libraries to something else.

[Racer159]

The bright side is that Zarf does not process config files like this:

package:
  deploy:
    set:
      test:
        aT: thingT
        bT: to-beT

so it would be easier to stay away from making this a breaking change.

[mjnagel]

Tacking onto this existing issue - besides maps/lists there are also issues with passing boolean values in (they end up getting cast into strings which can cause issues in certain helm templates due to "false" being a truthy value).

[justinthelaw]

Multi-line strings are not rendered properly either: https://github.com/defenseunicorns/uds-k3d/pull/112#discussion_r1778792074

EDIT: disregard, there was a typo in the indent type for the helm template. (nindent vs. indent)

[oates]

@Michael-Kruggel should this be moved to closed now?

[mjnagel]

@Michael-Kruggel should this be moved to closed now?

While the ZEP has been merged, I don't believe it has been implemented yet and this limitation still exists in zarf today (both in the latest release and in main).

[HerbBoy]

Will zarf add the ability to pass it an entire file of overwrites (at deployment time)? its a basic helm feature that is clearly lacking

[mjnagel]

Will zarf add the ability to pass it an entire file of overwrites (at deployment time)? its a basic helm feature that is clearly lacking

@HerbBoy I think this is currently being discussed/evaluated in ZEP 0021 - may be good to chime in there with any concerns/agreement with the plan.

[HerbBoy]

Will zarf add the ability to pass it an entire file of overwrites (at deployment time)? its a basic helm feature that is clearly lacking

@HerbBoy I think this is currently being discussed/evaluated in ZEP 0021 - may be good to chime in there with any concerns/agreement with the plan.

Not sure where exactly this is discussed. All I would love to see is the ability to use native helm value mapping.

example>

I package something on the lowside. I have overwrites on the highside to a my packages. I dont want to have to do all this zarf mapping to make something just work the way helm already lets you.

i should be able to do zarf deploy -f values.yaml containing the overwrites to my charts on the highside. It seems like a logical need to me.

Not to mention there are already existing pitfalls for how variables are handled today

[mjnagel]

Not sure where exactly this is discussed. All I would love to see is the ability to use native helm value mapping.

example>

I package something on the lowside. I have overwrites on the highside to a my packages. I dont want to have to do all this zarf mapping to make something just work the way helm already lets you.

i should be able to do zarf deploy -f values.yaml containing the overwrites to my charts on the highside. It seems like a logical need to me.

Not to mention there are already existing pitfalls for how variables are handled today

I believe it's covered in the overall proposal of the ZEP and would behave similar to your example (a new -f flag to pass in values files). There are also some user stories and examples below that.

[Racer159]

Thanks @mjnagel ! And yep that is the proposal over there - it and Zarf Enhancement Proposal 0017 are looking to make Zarf a little more Helm-like

[HerbBoy]

Question, what is the timeline on this. I saw this issue has been open for almost a year

[Racer159]

We are looking to get this completed soon but it likely will still take a bit more design to get into an alpha release state (will let @zarf-dev/maintainers speak more to specifics on timing though) - this issue was originally written to solve a slightly different issue and at least at Defense Unicorns we had been experimenting with other ideas in https://github.com/defenseunicorns/uds-cli (uses Zarf as a library behind the scenes) so are mostly just now (as of ~Feb) looking to take learnings back to Zarf

[dk-brightgr]

Any updates?