Changes in chart values.yaml aren't displayed in diff

[jwenz723]

I have a helm chart defined here that I am testing with. I have this repository cloned locally. I executed the following steps to evaluate helm-diff:

1. cd k8s/helm/
2. since the helm chart has not yet been installed into my k8s cluster I include the --allow-unreleased flag when I generate the diff: helm diff upgrade --allow-unreleased testgocolor ./gocolor
3. install the chart to my cluster: helm upgrade -i testgocolor ./gocolor
4. make a change to the gocolorEnv.color property in the charts values.yaml file (note: I am modifying the values.yaml file contained within the chart root, not a custom values.yaml file that I pass to helm with the --values flag)
5. I try to generate a diff: helm diff upgrade --allow-unreleased testgocolor ./gocolor

When the last command is executed I get no output, i.e. no diff is detected. Is this expected behavior?

I have found that a diff is generated if I specify the --reset-values flag like: helm diff upgrade --allow-unreleased --reset-values testgocolor ./gocolor.

[stale[bot]]

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

[mumoshu]

Came from #250. As I have never realized this issue myself, it sounds like a very nasty bug. Thanks for reporting! Let me check #250

[stale[bot]]

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

[jnoordsij]

I still seem to run into this bug on the latest version, any updates on this issue?

[mumoshu]

@jnoordsij ~~From which helm-diff version did you start to see your issue?~~ I don't have any update other than my last comment. Would you mind sending us a whole project for reproduction, or mind helping us contribute a fix? Thanks!

[jnoordsij]

The case mentioned at the start of the issue probably still is displaying an empty diff. I don't have a local setup atm I can use to verify this, as it is very similar to my usecase.

I think the problem is this: https://github.com/databus23/helm-diff/blob/master/cmd/helm3.go#L108 It seems that this behavior might have been present in Helm v2, but never has been in v3. So if you now change values in the values.yaml part of your chart, running helm upgrade <release-name> <chart-dir> will apply those changes, but using helm diff shows an empty diff as it forces the --reuse-values flags which then in turn ignores the changes.

[mumoshu]

@jnoordsij Thanks a lot for sharing your insight! Just confirming, but does that basically mean helm3 defaults to --reset-values?

[jnoordsij]

Ah I think I understand it now (see https://medium.com/@kcatstack/understand-helm-upgrade-flags-reset-values-reuse-values-6e58ac8f127e and in particular also the comments!):

• if one specifies --reuse-values, Helm uses the values provided in the latest deployment and only overrides those keys that are manually provided in the cli via various flags; value changes in values.yaml are ignored
• if one specifies --reset-values, the exact opposite happens, values are taken from values.yaml and overrides from cli-provided flags are applied; current deployment values in the cluster are ignored
• if one specifies neither of these flags, a hybrid behavior is applied on a per key-value pair basis: if a key was previously set directly from the values.yaml file, it will be changed on upgrade (similar to --reset-values); if a key was previously set through cli flags, it won't be changed/reset on upgrade (similar to --reuse-values) UNLESS new cli flags are provided in which case the value is reset to the values.yaml value (similar to --reset-values), irrespective of wether this particular key is present in the clif flags

So conclusion: the --reuse-values and --reset-values are not fully complementary options, and providing neither results in strictly different behavior.

Note: I also think the Helm 2 and Helm 3 behavior is actually the same.

[stale[bot]]

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