render-helm-chart function changes

[natasha41575]

• Support multiple values files in RenderHelmChart functionConfig (helmChartInflationGenerator: Support multiple helm values files kubernetes-sigs/kustomize#4219)
• Make the repo field optional to support authentication with private repositories (Support helm authentication for helm chart repositories. kubernetes-sigs/kustomize#4335)
• Support other requested options for helm template, such as api-versions, name-template, and skip-tests.

EDIT: Removing create-namespace and skip-crds because I'd misunderstood what they do; I don't think they will provide value here as IIUC they involve communication with the cluster.

This is a breaking change, and will require a version bump.

[natasha41575]

cc @yuwenma

[mengqiy]

Same comment here. tmp/ or /tmp?

[natasha41575]

For chartHome, the default is tmp/. IIUC when run in a container, the code is running at the root so it becomes the same thing as /tmp. However for chartHome it is important to distinguish, because when run locally (i.e. exec) it will look for files in tmp/charts in the current directory by default, not /tmp/charts. I have updated the containerized valuesFiles examples to use /tmp to be explicit, but chartHome is tmp and not /tmp intentionally.

[mengqiy]

Is hex.EncodeToString(md5.Sum(input)) a common practice in kustomize?

I guess hex.EncodeToString(hash[:]) can be simplified to hex.EncodeToString(hash), right?

[natasha41575]

It is not something we do in kustomize, but the hasher we have in kustomize hashes an entire RNode rather than a string, the code is here: https://github.com/kubernetes-sigs/kustomize/blob/master/api/hasher/hasher.go

Alternatives here could be to use the kustomize's hasher and do something like hasher.SortArrayAndComputeHash([]string{path}) - but we are not using this anywhere in kustomize so I am unsure how reliable it is. Or try something like the kubernetes deep hasher object.

However I prefer to use hex.EncodeToString(md5.Sum(input)) because it seemed like the simplest thing to do here.

I guess hex.EncodeToString(hash[:]) can be simplified to hex.EncodeToString(hash), right?

The latter doesn't compile, because hash is type [16]byte but hash[:] is type []byte.