Allow passing adding a source repo for Helm values

[servo1x]

Summary

Follow up on #2682, having the ability to have a git source for values.

Motivation

We have a git monorepo which currently hosts applications that will reference different versions of the same chart. It's really annoying to have to create a local chart every time we want to update a application to reference a different version.

We also follow the application of applications pattern, and if you are using helm 1st class with chart where there are lot of values (100+ lines), it becomes really painful (our app of apps helm chart does not define each app individually, instead - we pass in an array of helm charts and value paths and loop over that to create argocd applications).

Proposal

...
  source:
    repoURL: https://kubernetes-charts.storage.googleapis.com
    chart: my-chart
    targetRevision: 1.0.0
    helm:
      valuesRepo: [email protected]:example/repo.git
      valuesFiles:
        - values/some/value.yaml

[alexec]

Did the solution in the other issue help with this one?

[servo1x]

It's what we're currently doing but we would like move away from that. Currently we have to create local charts for N versions and it becomes very burdensome. It would be a lot nicer if we could reference the chart from the helm repo and use values in the located in our monorepo.

Currently we have a monorepo with values and local charts which have requirements that ref the actual chart...

charts
|[email protected]
|[email protected]
|[email protected]

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[ivanovaleksandar]

Is there any progress on this issue? It seems like a great way to separate runtime environment specific config from a general chart design config.

[perezjasonr]

Yes please imo is a must if argo is to support helm deployments. absolutely +1 this issue, the values file in a chart should be default values for the chart itself. Being able to reference a git repo just for values separate from the chart would be huge and I think many will want this functionality.

[servo1x]

Hm, not sure this request makes sense anymore.

The ArgoCD way of referencing a local helm chart with the actual chart as a dependency makes more sense now because at least the values are in sync with the chart version and now that helm values can be specified in the application crd as well, it kind of removes the purpose for this as you could write a helm chart to render the Application with the values or something.

Issue with having a separate helm chart and values, is how the two could be kept in sync. For example if the helm chart at v1 is updated to v2, and v2 introduces non backwards compatible changes with values, the sync would fail until it's resolved. Or the v2 chart gets synced with the v1 values and undesired defaults caused certain resources to be synced in an undesirable way.

I'll close this request as I think either having a psuedo helm chart with the actual helm chart as a dependency or defining the helm values in application crd makes more sense to do.

[perezjasonr]

I disagree, when someone provides a values file they are just supplying their desired values. the values file in the actual chart itself is just the default values. when someone provides their own values with a helm call they are overriding some and omitting many of them and those values are detached from the designed chart. someone's desired values should not be in the helm chart itself (or I should say it shouldn't HAVE to be). The helm chart is just supposed to be referenceable and the ability to check in and version control your values independent from the actual chart seems like a deliberate intent (i would think).

or to put it another way, to force the coupling of the values file and the chart for one install scenario means that we cannot design a helm chart, have it referenced by several environments, each with their own values file. For each environment w/ its values file they have to each have their own copy of the chart. Or reverse: the helm chart has to have a values file on top of the original for every possible install/environment...even if you dont want to give permission to push the values file to the chart to some consumer but you want them to be able to use the chart (for example)...For obvious reasons this wont scale well and has all kinds of ramifications.

the ability to provide inline values in the application object is nice but in my opinion to not allow it to be referenced in a git repo goes against the spirit of gitops.

Unless I'm misunderstanding what was said, thats just my 2cents.

[perezjasonr]

im opening this under my own enhancement request. I think this should still be pursued. #5826