Argo CD CLI app diff/sync to local manifest always fails on **Windows** operating system

[chris-codeflow]

Checklist:

• I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
• I've included steps to reproduce the bug.
• I've pasted the output of argocd version.

Describe the bug

Argo CD CLI app diff and app sync with --local flag doesn't work on Windows operating system.

To Reproduce

1. Create and sync an app (referencing a Helm chart) from a Git repository.
2. Clone the Git repository and make a change without committing it.
3. Use the Argo CD CLI to either view the difference or sync the app using the --local flag (for example: argocd app diff test --local ./chart).

Expected behavior

The Argo CD CLI either shows the app manifest difference(s) between the live and local app manifest (if using argocd app diff) or can sync the app to match the local app manifest (if using argocd app sync).

Screenshots

The Argo CD CLI always displays an error stating that the values.yaml file (in the Git repo) resolved to outside of the repository root, as follows:

time="2022-10-14T14:55:37+01:00" level=fatal msg="value file 'values.yaml' resolved to outside repository root"

No combination of paths or use of the --local-repo-root option can resolve the error.

Version

argocd: v2.3.4+ac8b7df
  BuildDate: 2022-05-18T13:11:31Z
  GitCommit: ac8b7df9467ffcc0920b826c62c4b603a7bfed24
  GitTreeState: clean
  GoVersion: go1.17.9
  Compiler: gc
  Platform: windows/amd64
argocd-server: v2.4.11+3d9e9f2
  BuildDate: 2022-08-22T09:13:16Z
  GitCommit: 3d9e9f2f95b7801b90377ecfc4073e5f0f07205b
  GitTreeState: clean
  GoVersion: go1.18.5
  Compiler: gc
  Platform: linux/amd64
  Kustomize Version: v4.4.1 2021-11-11T23:36:27Z
  Helm Version: v3.8.1+g5cb9af4
  Kubectl Version: v0.23.1
  Jsonnet Version: v0.18.0

Logs

None

[chris-codeflow]

I analyzed this bug and found the root cause in the file /util/io/path/resolved.go. Both the resolveSymbolicLinkRecursive and ResolveFilePath functions assume the directory separator to be the *nix / character, which is not the case for Windows operating systems.

I changed the functions to use string(os.PathSeparator) instead of the hard-coded string "/" and rebuilt the CLI for Windows. This resolved the issue. I will submit a PR for the fix.