feat: Experimental support for Helm 3.0.0-beta.3

[mumoshu]

Tested with helm diff upgrade only. Changes for other helm-diff sub-commands will be made in coming weeks.

Changes:

• Migrated from Glide to Go modules as helm-diff was unable to build with Glide due to bunch of missing transitive dependencies probably due to that some projects are not managed by Glide
• Auto-detection of the plugin context(helm 2 or 3)
• helm diff upgrade has been enhanced so that it turns into Helm 3 mode

Pre-requisites:

• You need to helm plugin install with helm of 3.0.0-x as the plugin installation directory has been changed from that of helm 2.x.

[databus23]

@mumoshu ❤️ I started looking into this yesterday. Will review/test first thing on Monday.

[mumoshu]

@databus23 Hey! Thanks for your response ☺️

I'd appreciate it if you could also take a look into #150 as well. The implementation is similar except that how much changes are made to existing sources, and #150 has a broader feature coverage!

[mumoshu]

@databus23 Btw incorporating helm 3 dependencies triples helm-diff binary size:

helm 2 ver:

$ ls -lah ~/.helm/plugins/helm-diff/bin/diff
-rwxr-xr-x  1 c-ykuoka  staff    16M  9  6 23:04 /Users/c-ykuoka/.helm/plugins/helm-diff/bin/diff

helm 3 ver(build from this PR):

$ ls -lah ~/Library/helm/plugins/helm-diff/bin/diff
-rwxr-xr-x  1 c-ykuoka  staff    50M  9  7 17:19 /Users/c-ykuoka/Library/helm/plugins/helm-diff/bin/diff

I have no idea how we can avoid this without improving things on helm-side.

Initially I thought this should be like around 30M and removing the helm2 support in the future bring it back to the original size. But I now realize that it can be impossible. We' need to import almost everything from helm3 as helm3 does more on client-side, compared to that the dependency was basically API and tiller client only for helm2.

Anyways, I just wanted to let you know.

[databus23]

@mumoshu Thanks again for starting to work on this.

We' need to import almost everything from helm3 as helm3 does more on client-side

This is an important point I've been thinking about in the past days. I think this poses a deeper problem than the size of the binary. Now with tiller gone, and all the rendering done locally the plugin would need to be compiled against the same version of the helm binary being used. Otherwise there might be differences in how templates are rendered. For helm diff this means the diff could be different from what is actually applied by the helm binary.
While tiller was a pain in general it was very beneficial for this plugin that the rendering happened remote on the server with the same engine that rendered the chart when upgrading a chart with the main binary (tiller).
Even if we would get our act together and publish this plugin in lockstep with helm versions there could still be weird problems when a user has multiple versions of helm3 installed for multiple clusters because they all share the same plugin folder.

I personally would like to avoid the situation where we need to keep up with helm's release cycle. I quite like that this plugin uses an older version of helm and still works with newer versions of helm without the need to rebuild.

Currently I see two options that could avoid this for helm3:

• We shell out to helm template to generate the manifest
• We try to integrate diff as a proper subcommand of the main binary as suggested here:(How to show changes before running helm upgrade? helm/helm#3156 (comment)

I see pros and cons in both approaches. Keeping this a separate plugin allows us to move quicker and add more features and subcommands then if this would be part of the official helm codebase. On the other hand having diff be a builtin feature like helm template would be very nice from a users perspective.
What do you think?

[jonasrutishauser]

Currently I see two options that could avoid this for helm3:

• We shell out to helm template to generate the manifest
• We try to integrate diff as a proper subcommand of the main binary as suggested here:(helm/helm#3156 (comment)

The first option would be simple to implement such that the same code would work for both helm versions.
In this case we could use helm template and/or helm get to get the manifests.
This way it should be mostly independent of helm's release cycle and the binary can stay small.

There is only one thing which bothers me. Helm 3 uses now 3-way strategic merge patches and i don't know how this plugin should handle this.

Nevertheless if i have some time i will try to implement a PR for the first option.

[mumoshu]

@databus23 Good point!

I like the first option as the starting point as it seems more feasible and allows users to migrate to helm 3 earlier.

In the longer term upstreaming diff definitely make sense. However it would take time as it likely require us to write some proposal and talk about maintenance(I believe we should stand as maintainers of the upstreamed diff sub-command but not sure how the process goes. So trying to address helm 3 support with upstreaming requires us to resolve two problems together, implementation and governance things.

[jonasrutishauser]

If created #151 for the first option.

[databus23]

Closed in favour of #151