support symlinks

[Trass3r]

Typical native Linux builds contain a lot of symlinks. That inflates the upload times and massively increases the artifact sizes.

##[debug]File: 3393/3605. /opt/clang/lib/libclang-cpp.so.11git took 81461.559 milliseconds to finish upload
##[debug]File: 3394/3605. /opt/clang/lib/libclang-cpp.so took 81832.023 milliseconds to finish upload
##[debug]File: 3395/3605. /opt/clang/lib/libclang.so took 983.696 milliseconds to finish upload
##[debug]File: 3396/3605. /opt/clang/lib/libclang.so.11 took 978.577 milliseconds to finish upload
##[debug]File: 3397/3605. /opt/clang/lib/libclang.so.11git took 993.718 milliseconds to finish upload

Version

• [ ] V1
• [x] V2

Environment

• [ ] self-hosted
• [x] Linux
• [ ] Windows
• [ ] Mac

Run/Repo Url https://github.com/Trass3r/llvm-project/runs/849655143

[konradpabjan]

I don't quite understand the problem 🤔 Could you elaborate a little more on what the expected behavior should be?

Looking at your run, the two files libclang-cpp.so.11git and libclang-cpp.so had very very large upload times because they were over 4 MB in size so they were uploaded in chunks (this is normal for large files). They have slightly different logs/output if you look at the output just above your screenshot.

The time that you see is the sum of all the calls to upload the individual files.

[Trass3r]

libclang-cpp.so is a symlink to libclang-cpp.so.11git as usual.

[stefanluptak]

I am running into this too. Is any ETA available, please?

[p--b]

As far as I can see, this is because of https://github.com/actions/upload-artifact/blob/ee69f02b3dfdecd58bb31b4d133da38ba6fe3700/src/search.ts#L16 with no available mechanism to override.

Would you accept a small PR to provide a follow-symlinks opt-out as a boolean input, as recommended by https://www.npmjs.com/package/@actions/glob#recommended-action-inputs ?

[staronline007]

Ok, it urgent call for the MTI

[shakfu]

I'm not sure it's the same problem but I am finding in v2 that is I have uploaded a macos .bundle which itself contains a .framework bundle and the latter has internal symlinks (Header, Version, etc..), after upload the symlinks are gone and have become duplicate folders of what linked to.

Can someone confirm that this is the same or a similar issue in this case, please?

[antonpirker]

@shakfu your stated scenario is the same issue.

[wxtim]

I've just come across this issue trying to use this action.

[shakfu]

@antonpirker

I find this occurs when I use cp -r <src> <dst> instead of cp -a <src> <dst>

[SteveDevOps]

This happened to us on nextjs project / next bin path which is a symlink from .bin. By the time build makes it to azure linux appservice, the app can't spin up its container correctly / can't find module because symlink is missing. Background: https://azureossd.github.io/2022/10/18/NextJS-deployment-on-App-Service-Linux/#note-about-symlinks-why-next-start-may-fail-in-certain-deployment-scenarios -- We fixed by putting full path in app startup cmd on appservice. Other way is full path in package.json (instead of just: yarn start or next start)

[soundasleep]

In #508 the lack of symlink support seems to break MacOS code signatures/notarization. Using tar to compress the folder first seems to work.

[PepeANZ]

I have opened up a PR to fix this https://github.com/actions/upload-artifact/pull/544

[sanjacob]

Why not support this as an opt-in? Is there a reason on github's side?

[eXhumer]

If anyone wants to use preserve links instead of following them in artifacts during upload, you can use eXhumer/upload-artifact@0b7d5f5684d3f642f978d2faad9ade64f5b4dd57. It is based on the latest upload-artifact version 4.3.6.

https://github.com/eXhumer/eXViewer/blob/119ec1b0081eeeadf1b371dd873d585ef22f0b32/.github/workflows/build.yml#L104-L112

I currently use it to build my macOS application package ZIP and it no longer breaks the application without needing to pre-ZIP before using upload-artifact