helm-diff
helm-diff copied to clipboard
RFE: helm-diff flags via envvars?
It seems like good idea to not reinvent the wheel and supporting all helm-diff args in external programs, but to allow helm-diff to pick up any valid CLI arg via environment variable.
This idea born from trying to use fresh --normalize-manifests flag in helmfile (https://github.com/roboll/helmfile/issues/2053):
Probably a better approach would be to enhance not helmfile but helm-diff to be able to enable the flag via an envvar,
like HELM_DIFF_NORMALIZE_MANIFESTS=true, so that you can run helmfile like HELM_DIFF_NORMALIZE_MANIFESTS=true helmfile apply.
What do you think?
Sounds good!
I believe this can be implemented like #336. Your contribution is much appreciated!
#336 is about adding envvar support just for one flag. I think that better approach is to implement future-proof mechanism for all flags (just like "pip" do, for example).
@evgkrsk Hey! Thanks for the feedback. I generally agree- but note that there might be only a handful of flags that makes sense to be configurable via envvars.
-color (Implemented)
three-way-merge(Implemented)normalize-manifests(TODO)find-renames(TODO)
and maybe:
suppress(TODO)strip-trailing-cr(TODO)
If a such future-proof mechanism turns out to introduce too much complexity to code compared to the benefit, I don't mind about a few code repetitions.
For posterity's sake, I commented in #361 that no-hooks should be a flag-only option.
For posterity's sake, I commented in #361 that
no-hooksshould be a flag-only option.
I'm trying to use with helmfile command. If I set the HELM_DIFF_USE_UPGRADE_DRY_RUN=true, it resolves the differences regarding the apiVersions diffs but shows me the removal of all helm hooks resources, with a huge output because I have a lot of them.
Without the possibility to set the --no-hooks arg through an env var I cannot omit the false hooks diffs (false because, for instance, a role or a configmap hook will not be removed).
@carlosrmendes Hey. Thanks. What you've described sounds more like an issue in helm upgrade --dry-run that it doesn't render manifests for hooks? Probably the right way forward would be to fix helm-diff to somehow configure helm upgrade --dry-run to include hooks.
yes, makes sense, definitely that is the best way to follow. I've just already tested only the command helm upgrade --dry-run, and yes, it shows me all the hooks as if they were to be removed.
@carlosrmendes Hey! I just ran a quick manual test and helm upgrade --dry-run foo stable/mysql does render hooks, for example. I've tried helm template foo stable/mysql and it did the same. It looks all good. I'm a bit confused.
Probably I misread your earlier comment. You want helm-diff to exclude diff on hooks from the output while you do want helm-diff to detect changes on hooks, right?
Then that's not where no-hooks are supposed to be used. If you used no-hooks it won't detect changes on hooks at all, which results in helmfile not trying to apply the changes at all when changes were made only on hooks.
Maybe what you want is more like --suppress and --suppress-secrets which controls the output but not the diff itself?
sorry @mumoshu, the command that is omitting the hooks is the helm diff upgrade --dry-run not the helm upgrade --dry-run.

Ah, gotcha! helm-diff currently parses MANIFEST section of helm upgrade --dry-run only so that's why helm diff upgrade with the three-way-merge option is missing the entire hooks from the diff. Sounds like it worth a dedicated github issue.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Would love to be able to set the context param via envvar for use with helmfile.
EDIT: Turns out this is already directly supported by helmfile diff --context n. Nevermind!
any update on this one? would really great to have support for normalize-manifests and find-renames.
I'd love to be able to override the defaults, currently I need to provide -C5 everytime I run helm diff, would be great if I could do this by default via an envvar or even a config file or something.