[helm] expand extraObjects templating

[TheRealNoob]

PR Description

Expand extraObjects to be far more flexible to the consumer of the chart. Couple top of mind use cases

1. By allowing extraObjects as a map, we can now split it across different values files, including encrypted ones.
2. The previous {{ tpl (toYaml .) $ }} did not allow templating of key names (referencing key, value pairs). The most common case where someone would want to do this is to when defining a new object that imports the standard labels {{ include "alloy.labels" . }} or {{ include "alloy.selectorLabels" . }}.

Which issue(s) this PR fixes

None

Notes to the Reviewer

I've tested this pretty extensively in other projects. I looked at seeing what I could do for testing here, but to do any kind of adequate testing in this scenario, requires more than simple "does it template" tests IMO. I have a helm-unittests for this that I've written which I'm happy to share. Note that it uses .Values.manifests and not .Values.extraObjects.
https://gist.github.com/TheRealNoob/ca7dee0e862a4e5526a115d54e863ec9

PR Checklist

• CHANGELOG.md updated
• Documentation added
• Tests updated
• Config converters updated

[skhtor]

Also eager for this to be merged. YAML merging is very useful and keeps our env-specific values files small.

[ptodev]

Thank you for the PR! I'm not very familiar with Helm... I suppose this makes sense but it'd be nice if @petewall could sanity check it before merging 😆

[ptodev]

Is it possible that it's neither a map nor a string? E.g. could it contain numbers?

[TheRealNoob]

It could, and we could template that, but it would yield invalid kube yaml so ultimately would be rejected. The user does need to define multiple fields, at least a minimum to render valid yaml. As far as I can think, these are the only two object types that would allow defining a complete object.

[petewall]

I think it's fine. I'd love to see some more examples in the values.yaml comments, especially with the whole "if its a map, the keys are thrown away". That's non-obvious to me, and we should be very careful adding things that might contribute to confusion.

[TheRealNoob]

I use this template internally on one of our charts and recognizing it's variability is quite wide and complex, I wrote out a helm-unittest case for it. Happy to share it here. Note my chart defines the field as manifests and not extraObjects.
https://gist.github.com/TheRealNoob/ca7dee0e862a4e5526a115d54e863ec9

[TheRealNoob]

I added another example of using list, but I see your point about the confusion of using dict. Do you have any thoughts on how that could be better-communicated without making the examples doubles the length?

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[TheRealNoob]

@ptodev do you need anything from me to keep this moving forward?