Support Windows

[jkroepke]

Goal:

• Run helm plugin install from windows cmd
• Run helm secrets from windows cmd
• Support sops.exe if no sops installed on WSL. (This supports gpg programs like gpg4win)

[erihanse]

@jkroepke do you know if there is a roadmap for windows support? We're getting

C:\Windows\system32>helm plugin install https://github.com/futuresimple/helm-secrets --version 2.0.2
Error: exec: "sh": executable file not found in %PATH%

[jkroepke]

@erihanse I tought no one request it.

One question:

do you have installed Git for Windows or WSL(Ubuntu Bash) on your system?

I saw you are using the old futuresimple version.

What the error if you try

helm plugin install https://github.com/jkroepke/helm-secrets

?

[philomory]

For my part, helm plugin install https://github.com/jkroepke/helm-secrets works perfectly, but when I try e.g. helm secrets --help I get

Error: fork/exec C:\Users\adam.gardner\AppData\Roaming\helm\plugins\helm-secrets/scripts/run.sh: %1 is not a valid Win32 application.

I do have both Git for Windows and WSL2 installed.

[philomory]

Since I do have sh available, I was able to fix it by manually editing the command field in plugin.yaml to say sh $HELM_PLUGIN_DIR/scripts/run.sh instead of just $HELM_PLUGIN_DIR/scripts/run.sh (since Windows doesn't really have a concept of a "shebang")

[jkroepke]

@philomory

You could take a look at #28 and see if this works on windows, too?

[philomory]

@jkroepke Yes, that does appear to work. Obviously it's not going to work for someone who doesn't have any instance of sh anywhere on their PATH, but, having to have at least one of WSL or Git-for-Windows as a prerequisite doesn't seem too onerous.

[jkroepke]

Sure, correct. But I would rewrite the plugin in go nativly before going to write some powershell. 😄

[philomory]

So, the new windows sh.cmd doesn't seem to work for me or my coworkers. Previously, when running just sh $HELM_PLUGIN_DIR/scripts/run.sh, everything seemed to work for us. Now, with the use of the new sh.cmd nothing works anymore. We constantly get the message, "The system cannot find the path specified". I've not yet dug into the script to figure out exactly what's going on, I'll let you know what I find.

[jkroepke]

I'll let you know what I find.

Thats a lot!

I just test it on my Windows machine. Since there is no default shell, I had to handle multiple cases (cygwin, git for windows, wsl) and different variations. There was no sh by default available.

The sh.cmd prefers a shell from windows environment first, because I thought if helm-secrets runs in WSL, it can't interact with a gpg deamon runs under windows, eg. gpg4win. But it's possible to force a shell/environment.

[philomory]

So I can see a few things that seem a bit weird. The windows command in plugin.yaml says cmd /c $HELM_PLUGIN_DIR/wrapper/sh.cmd $HELM_PLUGIN_DIR/scripts/run.sh"; but, $HELM_PLUGIN_DIR/wrapper/sh.cmd doesn't exist, it's $HELM_PLUGIN_DIR/scripts/wrapper/sh.cmd.

After correcting for that issue, the plugin actually works, although there's another (not-fatal) weirdness: If you call helm secrets foo, then the command passed to cmd /c is $HELM_PLUGIN_DIR/scripts/wrapper/sh.cmd $HELM_PLUGIN_DIR/scripts/run.sh foo. So, the arguments to sh.cmd will be $HELM_PLUGIN_DIR/scripts/run.sh foo. So far, so good.

However, inside sh.cmd, on line 47, we call "sh" "%HELM_PLUGIN_DIR%\scripts\run.sh" %*. %* at this point contains %HELM_PLUGIN_DIR/scripts/run.sh foo, so arguments ultimately passed to sh are $HELM_PLUGIN_DIR\scripts\run.sh $HELM_PLUGIN_DIR/scripts/run.sh foo. This actually works, but it's a little confusing and I could see it being a source of issues in the future if the contents of run.sh changed.

[jkroepke]

arguments ultimately passed to sh are $HELM_PLUGIN_DIR\scripts\run.sh $HELM_PLUGIN_DIR/scripts/run.sh foo

Yes, the behavior is catched by

helm-secrets/scripts/run.sh

Lines 83 to 86 in e67afdb

	# ./run.sh vs bash run.sh
	if [ "$(basename "$1")" = "run.sh" ]; then
	shift
	fi

This actually works, but it's a little confusing and I could see it being a source of issues in the future if the contents of run.sh changed.

I know this. Additionally it's increase the complexity dramatically.

If we are get more issues, I'll restore the old behavior.

The reason for this, helm-secrets was not running out of the box on my windows systems.

[jkroepke]

I'm running Windows tests inside GH Actions now. That should avoid some mistakes on windows systems.