[BUGFIX] Provide gitPath for Windows to avoid failures on windows-2022 (GitHub-hosted runner)

[ochococo]

Problem:

Observed error on windows-2022 (GitHub-hosted runner) that git command cannot be found.

Issue:

Cannot find git executable on on windows-2022 (GitHub-hosted runner) #136

Solution:

This path improvement makes use of existing path.js to resolve and return correct git.exe path for Windows, leaving the executable name as it was for other operating systems.

Caveats:

No idea how and why this c://progra~1//git//usr//bin//git.exe mumbo-jumbo works but it apparently did for other executables so figured it should work for git.exe (and it does).

[ochococo]

@sebastiankugler 👀 please 🙂

[sebastiankugler]

Seems reasonable, correct and in line with how we treat the other executables.

[ochococo]

All checks have failed, should I worry @sebastiankugler ?

[sebastiankugler]

We need to understand ourselves, but we're on it! No need to worry 🙂

[mpdude]

I'm a bit concerned regarding BC: What about people using self-hosted Windows runners where git is in the PATH, but not at the absolute path given here?

Should we, in general, make all the paths configurable through action inputs?

Would a CHANGELOG entry be good enough, given that we're still at 0.x releases?

Could paths.js more specifically detect GitHub-managed windows-2022 runners and apply these paths only then?

[ochococo]

I'm a bit concerned regarding BC: What about people using self-hosted Windows runners where git is in the PATH, but not at the absolute path given here?

Same here but if current strategy is wrong, this PR won't make it any worse, right? Why would we use agent related from current absolute path and git exec from another location?

Should we, in general, make all the paths configurable through action inputs?

That would be definitely a major improvement, one can only benefit from such flexibility. Seems like a bigger feature and effort.

[mpdude]

Same here but if current strategy is wrong, this PR won't make it any worse, right? Why would we use agent related from current absolute path and git exec from another location?

Yeah, valid point. Every change breaks someone's workflow, but maybe we can accept this risk here.

[mpdude]

@ochococo Now that I take a step back, what would you think about having homePath, but sshAgentCmd (or ...Command) and the same for other items that refer to binaries?

I can make the change for you if you agree.

[ochococo]

I would then argue this is not a command but rather a path to command (or executable if you will).
Bike-shedding obviously, not a strong objection from me, UTY

[mpdude]

The problem with the workflows probably is that secrets are not available when the workflows are started for PRs from external contributors. Not sure yet how to best address this.