Support version declaration and update build-time install

[vdice]

Support a Helm version declaration and use this value, when provided, to download the corresponding helm cli binary at build-time. For example, the helm mixin declaration in a Porter manifest could look like:

mixins:
- helm:
    version: v1.15.1

We'd then update the installation steps/lines added to the generated invocation image Dockerfile to download the v1.15.1 helm binary.

[MChorfa]

@vdice, Can you assign this to me

[MChorfa]

Proposal

I have started working on helm3 mixin support: https://github.com/MChorfa/porter-helm3 and I want to propose to adapt the helm2 mixin regarding the version that was requested at Buildtime, thus the behavior of the mixin will run accordingly. So, we don't have to maintain 2 projects that are very similar and prepare for the fade-out of helm2. WDYT?

[MChorfa]

Strategy:

• Make the Schema agnostic
• Set a global flag to determine which helm we are using
• Inject initialization services when required
• Handle/Update the command object with the required flags depending on the current helm

  Main Diff :

  Diff	Helm2	Helm3
  Schema	none	--purge is removed for uninstall step and --namespace is required for uninstall step
  Init	initTiller is required	initTiller Logic is removed
  Build	kubectl is not required	kubectl is not required
  Install	require --name flag	removed --name flag
  Uninstall	require --purge flag	removed --purge flag
  Upgrade	require --name flag	removed --name flag
  Invoke	no-change	no-change

[carolynvs]

@MChorfa Seems like there would be differences in the allowed yaml based on which version of the mixin that you are using then, correct?

If so, then the new combined helm mixin should definitely implement the lint command that was just put in place in the v0.25.0-beta.1 release so that it can validate that the porter.yaml is correct based on the version selected.

Another question to consider is what should the default version of helm be when the user doesn't select one? Or should version be required? You don't need answers now, just putting it out there for people to think about.

[MChorfa]

Hello @carolynvs, Actually, for install/upgrade the yaml's don't change. except for uninstall where purge is not allowed in helm3. Definitely the linter will be a very nice way to ensure the correct structure of the targeted Helm instance.

I guess the default version would be Helm3, because of easiness of installing and doesn't require Tiller and help people to move from 2 to 3.

Thank you,

[MChorfa]

Thank you @vdice , retrofitting back the same behavior to Helm3 mixin

[vdice]

@MChorfa when convenient, can you create a new issue with the notes/discussion around https://github.com/deislabs/porter-helm/issues/50#issuecomment-606344338 ? I think this can/should live on.

Closing this as it has been implemented in #64