Allow diffing between 2 different releases

[sstarcher]

We have several charts that we install a dozen of them. IT would be highly useful if we could diff between 2 different releases.

[mumoshu]

Hey!

What would be expected use-cases of this feature?

I guessed - You have a staged release pipeline. Each helm release corresponds to different versions/configurations of the same app, and taking diff of them allows you to review what's promoted to the next stage...

But it sounds like we can just use diff upgrade because you'd run helm upgrade anyway to upgrade a specific stage.

[sstarcher]

It would not these are not necessarily different environments. We have say different customers. Customer A, B, C, D, E and we would like to see what differs between them.

[mumoshu]

Thanks! That makes sense to me.

[codenio]

hi,

I would like to share some thoughts here.

scenario:

created two releases app-1 and app-2 using chart demo, with slight changes in values.

• currently presence of release name in the index/key ( ex: default, app-1-demo, Service (v1) ) for comparison, treats each object as a new release resulting in responce shown below

  
  

• the desired response would be. (temporarily generated by comparing object kind)

  

which would demand the following changes

• modifications to index/key for cross release comparison (ex: default, front-end, Service (v1) )
• addition of a unique id to each kubernetes object (ex: front-end) using labels, for comparison of objects across releases as they would have different names.

code changes can be viewed here. hope this would be helpful.
we could discuss further on this and come up with a solution.

suggestions and feedbacks..?

[sstarcher]

@aananthraj excellent I'll take a look.

[sstarcher]

Grabbed your modifictions and did a glide install and a build. Guessing the version of mergo is different

# github.com/databus23/helm-diff/vendor/github.com/Masterminds/sprig
vendor/github.com/Masterminds/sprig/dict.go:92:13: undefined: mergo.MergeWithOverwrite```

[sstarcher]

@aananthraj looks like you don't currently take into account when someone has multiple say ConfigMaps. I'll dig into verify my assumption.

- # Source: test/templates/apps-environment.yaml
+ # Source: test/templates/apps-uwsgi.yaml

[codenio]

Grabbed your modifictions and did a glide install and a build. Guessing the version of mergo is different

# github.com/databus23/helm-diff/vendor/github.com/Masterminds/sprig
vendor/github.com/Masterminds/sprig/dict.go:92:13: undefined: mergo.MergeWithOverwrite```

Yes there is an issue, with mergo, I manged to bypass it by using latest mergo pkg installed globally. (Deleted the pkg under vendor folder)

[codenio]

@aananthraj looks like you don't currently take into account when someone has multiple say ConfigMaps. I'll dig into verify my assumption.

- # Source: test/templates/apps-environment.yaml
+ # Source: test/templates/apps-uwsgi.yaml

Currently a release wirh one object of each kind works ( 1 deploy, 1 svc etc ).
Since object kind is used for matching in the nested loops, presence of more than one object kind ( say 2) Compares and diffs 4 times.

addition of a unique id to each kubernetes object (ex: front-end) using labels, for comparison of objects across releases as they would have different names.

Furthur modifications are required.

[codenio]

Currently a release with one object of each kind works ( 1 deploy, 1 svc, etc ).

This issue is resolved now, it would work fine for generic releases

@sstarcher and @mumoshu kindly have a look at the code changes in #131

[benmathews]

Grabbed your modifictions and did a glide install and a build. Guessing the version of mergo is different

# github.com/databus23/helm-diff/vendor/github.com/Masterminds/sprig
vendor/github.com/Masterminds/sprig/dict.go:92:13: undefined: mergo.MergeWithOverwrite```

Yes there is an issue, with mergo, I manged to bypass it by using latest mergo pkg installed globally. (Deleted the pkg under vendor folder)

Specifically

go get github.com/imdario/mergo
rm -rf vendor/github.com/imdario/