-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Ability to define custom template funcs via helmfile.yaml #245
Comments
@mumoshu I'm not sure if uncoupling the definition from the usage, i.e. putting the definition into the helmfile and the usage is in the template, is a good idea. It would hinder template reuse as you'd need to make sure to also copy the definition into the other helmfile which is using the same template. This could also lead to diverging definitions (some might view this as a feature) and confusing behaviour (from a user's viewpoint) if the definition is changed in one helmfile and not the other. I'd leave this for now and maybe reevaluate it in the future. It is as you write more of a convenience than a necessity. |
@elemental-lf Good point! Honestly at the time of writing this, I didn't pay much attention about u/x and the temlate reusability. But I do care about them! My original motivation for this was to make templates DRY. An alternative way that comes to my mind is to allow importing template helpers like helm does. But it seems challenging in another way, that is how to determine which template helper files to be loaded for the temlate being rendered. helm does so by looking for templates/_*.tpl. How the convention for helmfile would look like, especially when you have single template helpers file, that is wanted to be used from templates scattered in various levels of directories... |
@mumoshu I would shelve this topic for the time being to keep things simple. I mean we just want to render input values for Helm charts and not the charts themselves, right? |
@elemental-lf Sounds good. Thanks for all the feedbacks! Your examples does seem very... insightful. After seeing it, I started to more like shelling-out to a more serious command with something like Generally speaking, we shouldn't do too much in templates. |
Here's an example of a common use case in which some sort of parameterizable functions would be useful:
I'd need that boilerplate for each and every one of my dozens of releases. What I'd ideally like to do is something akin to this:
And then be able to define that template function, taking the project name as a interpolate-able parameter. |
@witten I have a similar use case where I have a chart that has about 10 lines of config currently per each of them in helmfile. Where 3 pieces of data are all that will normally differ. |
This is marked wontfix, but it's also still Open. Is that intentional? The In regards to Helm's comparable feature and |
We already have an issue for tracking the potential addition of |
In addition to #244, a kind of aliases or custom template functions to allow writing just
{{ myfunc "foo" "bar" }}
instead of writing{{ exec "./myfunc" "foo" "bar" }}
over and over would be convenient.How about enhancing the plugin proposal #214 to accept:
so that you call just call it like this in your values.yaml template:
The text was updated successfully, but these errors were encountered: