file that definitely exists can't be found for upload

[aryairani]

What happened?

I can ls /d/a/unison/unison/.stack-work/install/2736fb8a/bin/unison and get

-rwxr-xr-x 1 runneradmin 197121 105223168 Feb 12 16:35 /d/a/unison/unison/.stack-work/install/2736fb8a/bin/unison

i.e. the file exists.

But when I Run actions/upload-artifact@v4

  with:
    name: unison-windows-2019
    path: /d/a/unison/unison/.stack-work/install/2736fb8a/bin/unison

I get

No files were found with the provided path: /d/a/unison/unison/.stack-work/install/2736fb8a/bin/unison.
No artifacts will be uploaded.

What did you expect to happen?

If the file exists, I should be able to upload it.

How can we reproduce it?

I'm not sure, but here is a link to the run:
https://github.com/unisonweb/unison/actions/runs/7877254164/job/21493042315#step:15:2

Anything else we need to know?

The run works on macos and ubuntu.

What version of the action are you using?

v4

What are your runner environments?

window

Are you on GitHub Enterprise Server? If so, what version?

No response

[aryairani]

I guess both which and ls doing something misleading about .exe files (dropping the .exe suffix?) that actions/upload-artifact doesn't do. Probably something that should be documented.

[aryairani]

How can I find and upload-artifact an executable in a platform-independent way?

[amandastecz]

Same bug here =/

[amandastecz]

it worked for me: #232

[aryairani]

I'm already using an absolute path, so I don't think #232 is relevant.

[aryairani]

I guess the cygwin tools automatically add and remove .exe to executables, but upload-artifact doesn't apply the same transformations. That's why it's possible to ls foo to find foo.exe but return it as foo, and then upload-artifact will fail because foo does not actually exist, only foo.exe does.

My current workaround:

- step: set up environment
  shell: bash
  run: |
    if [[ ${{runner.os}} = 'Windows' ]]; then exe=".exe"; else exe=""; fi
    echo "artifact_name=foo$exe" >> $GITHUB_ENV
- step: upload artifact
  with:
    path: ${{env.artifact_name}}

Instead of:

- step: upload artifact
  uses: actions/upload-artifact@v4
  with:
    path: foo

Note that I didn't even realize the true filename was foo.exe, as all the cross-platform commands I use in the rest of the workflow refer to it as foo without issue and report its name as foo. So in that sense, it would be less surprising if upload-artifact accepted the name foo.

I guess foo.exe and foo could both exist and that would be problematic, and I can't speak to how cygwin handles this case.

[eitsupi]

I think this is related to #337.
It seems that absolute path on Windows is not supported.