file that definitely exists can't be found for upload

aryairani commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

amandastecz commented 9 months ago

Same bug here =/

amandastecz commented 9 months ago

it worked for me: https://github.com/actions/upload-artifact/issues/232

aryairani commented 8 months ago

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

aryairani commented 8 months ago

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 commented 6 months ago

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

BACBcnorris commented 2 months ago

I just had the same issue, my output directory had a period in it for example:

${{ github.workspace }}/.output/

and I would get the error, No files were found with the provided path.

I removed the period from output to make it

${{ github.workspace }}/output/

and now it works.

tested with upload-artifacte@v3 and v4.

tm1000 commented 2 months ago

https://github.com/actions/upload-artifact#uploading-hidden-files

actions / upload-artifact