You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great if in addition to a params file or params flag it could also just support environment variables. I think that makes the usage very simple, no flags to remember etc. Also in our current deployment setup we are already passing in these variables via env variables, so it would greatly simplify maintenance if I could just run ktmpl resource.yaml rather than having to mach it to the params flags.
Also running it locally becomes imo a bit simpler, e.g. VARIABLE="test" ktmpl resource.yaml
The text was updated successfully, but these errors were encountered:
Are you imagining that the environment variable form would be the equivalent of the --parameter option? That is, it wouldn't be possible to provide a value through an environment variable and also tell ktmpl not to do any Base64 encoding on it.
That is the current implementation yes. I was thinking of some way to tell ktmpl to not do any base64 encoding on the value but also not needing that use-case at the moment. We could add for example a special environment variable KTMPL_BASE64_PARAMETERS=variable,anothervariable and then it does treat those specified parameters as if they would have been passed in with the --base64-parameter flag.
It would be great if in addition to a params file or params flag it could also just support environment variables. I think that makes the usage very simple, no flags to remember etc. Also in our current deployment setup we are already passing in these variables via env variables, so it would greatly simplify maintenance if I could just run
ktmpl resource.yaml
rather than having to mach it to the params flags.Also running it locally becomes imo a bit simpler, e.g.
VARIABLE="test" ktmpl resource.yaml
The text was updated successfully, but these errors were encountered: