Incorrectly compressed output artifact on Windows

[kalb1]

Pre-requisites

• I have double-checked my configuration
• I can confirm the issues exists when I tested with :latest
• I'd like to contribute the fix myself (see contributing guide)

What happened/what you expected to happen?

Output archive artifact compress folder incorrectly in case of windows image. Instead of keeping the folder structure, it puts all files in the root folder and appends the folder names to the file names, e.g structure:
argo_test/
|----- test.txt

In the compressed artifact, there will be the empty argo_test folder and the file called argo_test\test.txt
The problem does not persist on Linux pods.

I assume this should be a 7zip misconfiguration.

Version

v3.4.4

Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: artifact-passing-
spec:
  entrypoint: artifact-example
  templates:
  - name: artifact-example
    steps:
    - - name: hello-win
        template: hello-win

  - name: hello-win
    nodeSelector:
          kubernetes.io/os: windows
    container:
      image: mcr.microsoft.com/windows/nanoserver:1809
      command: ["cmd", "/c"]
      args: ["mkdir argo-test && echo Welcome from windows container! > argo-test/test.txt"]
    outputs:
      artifacts:
      - name: hello-win
        path: /argo-test
        archive:
          tar:
            compressionLevel: 0

Logs from the workflow controller

-

Logs from in your workflow's wait container

-

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a mentoring request, please provide an update here. Thank you for your contributions.

[weretheone]

Unfortunately this issue is still affecting our environment. We was able to overcome the situation with disabling compression and handling the artifacts differently, but it would be nice to see this issue resolved some way.

[PeterKoegel]

This issue seems to be caused by the way how tar archives are created in util/archive/archive.go tarDir()

There the nameInArchive for each file is determined which ends up in the tar file as a file header. This works fine on Linux but on Windows a path with backslashes instead of forward slashes is written to the tar file. When such a tar file the is unpacked on Linux the result is as described above (the directory structure is lost and the complete path with backslashes is ending up in the filename).

[Transmitt0r]

So we should always use forward slashes in the header? Since that seems to work on both platforms.

[kalb1]

@Transmitt0r I tried with forward slashes as you can see in the example, but unfortunately it did not work fine for me.

[PeterKoegel]

@Transmitt0r Yes, changing the code to always use forward slashes in the header worked for me. After that the .tgz output artifacts produced by a Windows step could be used as input artifacts for Windows and Linux steps.

When opening the created .tgz files with something like 7-zip they also had the right directory structure only when they had forward slashes as directory seperators.

[kalb1]

@PeterKoegel Which version did you use for checking this?

[PeterKoegel]

@kalb I will create a pull request today with the changes I did to get it work. I had to change a line of code that creates the tar files and build my own argoexec container from that.

[kalb1]

Awesome, ty @PeterKoegel