fix: avoid exporting kubeconfig if not set

[yajo]

This will respect outer $KUBECONFIG by default, unless something is specified.

This fixes downstream builds that were failing with:

nix build .#kubenix
error (ignored): SQLite database '/home/yajo/.cache/nix/eval-cache-v6/e2c155d8289bbf5b9d7ff161ad125c5026e61dbadddaf55652c23ef99249c588.sqlite' is busy
error: Cannot build '/nix/store/askjbhnkiz6wwn17kk88xa2clgwc3ysi-kubenix.drv'.
       Reason: builder failed with exit code 1.
       Output paths:
         /nix/store/8hlx23350igvj88f0ghi6j74iazym4p1-kubenix
       Last 7 log lines:
       >
       > In /nix/store/8hlx23350igvj88f0ghi6j74iazym4p1-kubenix/bin/kubenix line 4:
       > KUBECONFIG='$HOME/.kube/config'
       >            ^------------------^ SC2016 (info): Expressions don't expand in single quotes, use double quotes for that.
       >
       > For more information:
       >   https://www.shellcheck.net/wiki/SC2016 -- Expressions don't expand in singl...
       For full logs, run:
         nix log /nix/store/askjbhnkiz6wwn17kk88xa2clgwc3ysi-kubenix.drv
         ```

         @moduon MT-1075

[adrian-gierakowski]

CI is failing

[yajo]

Should be fixed.

[yajo]

I pushed another commit that is slightly out of scope but:

• Requires the previous fix to work.
• Adds the use case why this is more important.

A command like this:

nix run .#kubenix -- apply -l kubenix/module-instance=one

Will now do what you'd expect.

With it, you can render a lot of manifests without having to apply them all at once.

Before, we were getting errors like:

line 2: set: u: invalid option name
line 3: set: o: invalid option name
error: unknown shorthand flag: 'l' in -l
See 'kubectl --help' for usage.
error: unknown command "kubenix/module-instance=instance-a" for "kubectl"

[yajo]

This should be ready to merge. Anything missing? Thanks!

[adrian-gierakowski]

I see this is fixing a regression introduced by your earlier PR. However the behaviour is still subtly different than before, since previously it was possible to override the kubeconfig at runtime by setting KUBECONFIG. While now if one sets kubeconfig it will not be irrecoverable. Also, if someone previously manually set kubeconfig to "$HOME/.kube/config", $HOME will not be resolved at runtime, due to quoting done by runtimeEnv

Can we please revert to old behaviour as I'd consider this a breaking change? Thanks!

[adrian-gierakowski]

I see this is fixing a regression introduced by your earlier PR. However the behaviour is still subtly different than before, since previously it was possible to override the kubeconfig at runtime by setting KUBECONFIG. While now if one sets kubeconfig it will not be irrecoverable. Also, if someone previously manually set kubeconfig to "$HOME/.kube/config", $HOME will not be resolved at runtime, due to quoting done by runtimeEnv

Can we please revert to old behaviour as I'd consider this a breaking change? Thanks!

scratch that, I prefer the new behaviour since:

1. not quoting values presents a security risk
2. if someone sets kubeconfig it's probably best best to keep it hermetic and not make execution dependent on env. User can still override with --kubeconfig flag

[adrian-gierakowski]

we should cut a 0.4 release in the near future