search

actions / upload-artifact

MIT License
3.25k stars 736 forks source link

[bug] Symlinks are preserved by default #590

Closed daskol closed 1 month ago

daskol commented 3 months ago

What happened?

Transition from v4.3.4 to v4.3.5 broke regular building pipelines because actions/upload-artifact does not derefernce symlink anymore by default and upload symlinks as is but not target files.

See "Upload StarPU libraries" job for details.

What did you expect to happen?

  1. Pipelines are expected to work as before.
  2. Symlinks are dereferenced by default.
  3. This action providesd special option/flag for (de)referencing symlinks (kind of -L/-l in common POSIX utils).

How can we reproduce it?

You can fork repo or create pull request and trigger pipeline on push event.

Anything else we need to know?

No response

What version of the action are you using?

v4.3.5 (no issue with the previous v4.3.4)

What are your runner environments?

linux

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

No response

erick-xanadu commented 3 months ago

This also affected us. Thanks @daskol for reporting this issue.

cbaeberle commented 3 months ago

589 Seems the same issue.

cipolleschi commented 3 months ago

Hi there! Riccardo from Meta, working in the React team and taking care of the React Native build pipeline on GH. This affected us as well.

daskol commented 3 months ago

@robherley Could we revert the changes in the latest release 4.3.5 and create a new release 4.3.6? After that, we can continue working on this issue.

robherley commented 3 months ago

Hey folks, we reverted & released a new version for v4.3.6 to address the regression.

sanjacob commented 3 months ago

It would be really nice if this behaviour could be opt-in instead #93 #508.

Edit: after testing it seems that not all symlinks are preserved

robherley commented 1 month ago

With v4.4.1, this is fixed:

icfaust commented 1 month ago

@robherley It seems that from the original issue steps 1. and 2. have been completed

What did you expect to happen?

  1. Pipelines are expected to work as before.
  2. Symlinks are dereferenced by default.
  3. This action providesd special option/flag for (de)referencing symlinks (kind of -L/-l in common POSIX utils).

Is there any timeline for delivery on step 3?

teo-tsirpanis commented 1 month ago

My action builds a Linux library and uploads it to a tarball. The library consists of a libmylibrary.so.1.0 and a symlink libmylibrary.so that points to the former file. Since 4.4.1, that file is not included anymore.

robherley commented 1 month ago

@icfaust I don't believe we're going to specifically work on (3) at this time, we were only focused on the regression

robherley commented 1 month ago

@teo-tsirpanis Do you have an example or a minimum way to reproduce?

I've added a symlink test to upload-artifact's workflow, as well as toolkit too.

teo-tsirpanis commented 1 month ago

@robherley

The job in question is Build-Native (ubuntu-latest, dev) and the symlink should be in lib/libtiledb.so in artifact tiledb-native-dev-linux-x86_64.

robherley commented 1 month ago

@teo-tsirpanis is it a relative symlink? Could you ls -la the contents before it's uploaded?

Looks like this job is failing to lstat the file: https://github.com/TileDB-Inc/TileDB-CSharp/actions/runs/11227543765/job/31209939977#step:7:20

Warning: ENOENT warning during artifact zip creation. No such file or directory
Error: ENOENT: no such file or directory, lstat 'libtiledb.so.2.27'

The relative link might not be getting resolved 🤔

FreyJo commented 1 month ago

We have the same issue as @teo-tsirpanis including the lstat warning. In our case, the symlink is created via CMakes set_target_properties, which seems to be good practice. See https://github.com/acados/qpOASES/pull/2

teo-tsirpanis commented 1 month ago

It seems to be a relative symlink:

teo@theodore-tiledb:~/code/TileDB$ ls -la build/Default/tiledb/libtiledb.so
lrwxrwxrwx 1 teo teo 17 Sep 19 03:25 build/Default/tiledb/libtiledb.so -> libtiledb.so.2.27
robherley commented 1 month ago

Okay, I'll look into a fix. For now feel free to pin to 4.4.0 if you are using relative symlinks.

robherley commented 1 month ago

I made a PR for toolkit, I'll have my team take a look:

@teo-tsirpanis @FreyJo do y'all want to test with the changes? You can try uploading with my branch version:

uses: actions/upload-artifact@robherley/v4.4.2
teo-tsirpanis commented 1 month ago

The workflow succeeded, thanks!

robherley commented 1 month ago

v4.4.2 is out, v4 will be updated shortly!

robherley commented 1 month ago

And v4 is released with the latest changes 🎉

robherley commented 1 month ago

v4 has been temporarily rolled back to v4.4.1 due to:

You can still use v4.4.2 for these symlink changes.

robherley commented 1 month ago

Closing this out, we preserve both relative and absolute symlinks and have added integrations test to prevent a regression.

All versions >= v4.4.2 (including v4) have this behavior addressed.