Make FilteredFilePatterns configurable

[hannomalie]

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]

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

[tkrullmann]

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]

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 :)