search

unbroken-dome / gradle-helm-plugin

A Gradle plugin for building, publishing and managing Helm charts.
MIT License
52 stars 55 forks source link

Make FilteredFilePatterns configurable #131

Closed hannomalie closed 2 years ago

hannomalie commented 3 years ago

Hey all, thanks for your nice work with the gradle-helm-plugin.

I don't know whether I have thought it through completely, but have you considered making the FilteredFilePatterns in https://github.com/unbroken-dome/gradle-helm-plugin/blob/master/helm-plugin/src/main/kotlin/org/unbrokendome/gradle/plugins/helm/tasks/HelmFilterSources.kt#L24 part of the task configurations, so that it can be overriden by the user?

My usecase is that I need a value from the build (who would have guessed) in a single template file in my helm sources. We indeed have many cases where just interpolating into the template would be nicer than interpolating into the values file and use go templating to get the value out of the templates.

Thanks :)

hannomalie commented 3 years ago

Hey guys, any response here? :) Would you like me to implement that as a pull request?

tkrullmann commented 2 years ago

Hi @hannomalie ,

sorry for taking some time to reply. Yes, this shouldn't be difficult to do. I think my initial implementation for this even made it fully configurable, but taking out some of the moving parts seemed like a good idea (there's already a ton of options for this plugin...)

Just out of curiosity, what kind of value are you injecting into the chart templates? I couldn't imagine one where it would not be cleaner to just add it to the values.yaml file instead. Having a template file pass through two different template engines seems a bit strange.

hannomalie commented 2 years ago

No problem :) we have a lot of service urls and config values that are either only used as environment variables for a pod or as identifiers in externalsecret resources that are just passed through values file for no good reason. The values are determined in the gradle build, where we know about the environment. That leads us to need to write config keys in three places... The build file, the values file and finally the pod or secret file. Would love to skip one, or even two (two by prerendering things in the build file :p ) and avoid some ugly conversion pitfalls with yaml and go templating...

Super nice you already implemented that, i will report when any issues :)