Closed jeffmccune closed 14 hours ago
Watch out for if we need to provide an escape hatch to allow the user to execute an user defined helm
. This might be a generic Execute
generator that executes any command that produces data on standard output.
Watch out for if we need to provide an escape hatch to allow the user to execute an user defined
helm
. This might be a genericExecute
generator that executes any command that produces data on standard output.
I like the idea of a generic executor, because that would also open the possibility to use our existing kustomizations as generators in holos. We have a mono repo with a lot of kustomizations (200+) and doing a big bang move to holos is not feasible, but having a kustomize generator would give us a nice incremental adoption path. It would also enable other rendering tools like jsonnet very easily.
Right now the helm generator is a bit special because it downloads the helm chart into the repo and adds logic to pass a values file. IMHO both features are not a good fit for a generic executor, but they would be required for helm template to work.
The helm generator needs to pass a values file to helm template
which current is implemented by writing a temporary values file to disk and passing --values path/to/tempfile.yaml
to helm template
. Instead of using a temp file for values, you could pass values to helm template via stdin. Passing in data via stdin in a generic executor makes sense and is something that other rendering tools like jsonnet could benefit from.
For the generic executor to run helm template
, it would need to know the local path to the chart. In our repo we already use https://github.com/Qovery/helm-freeze and the experience has been quite good. I already built a prototype to generate helm-freeze.yaml
from cuelang and its probably very easy to integrate this with holos as well. But maybe its a good idea to integrate such functionality directly in holos, improving the overall UX and developer flow.
@msteinhoff FYI, added the KubeVersion and APIVersions fields in #338 and released in v0.99.0
Add the ability to configure the helm template --api-versions flag.
We have prior art with how we handle Helm hooks with the
EnableHooks
field of core.HelmSee https://helm.sh/docs/chart_template_guide/builtin_objects/
Discussion
Proceed with adding new fields to
core.Helm
.