-
Notifications
You must be signed in to change notification settings - Fork 695
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug] v4 hangs uploading from mac runners #527
Comments
Add a workflow to try to reproduce the failure we see in teleport.e with upload-artifact on macOS, reported in actions/upload-artifact#527. Reproducing this in a public repo with minimal steps will make it easier to diagnose this issue.
Using the following workflow has reproduced the issue multiple times for me:
Please note that I was testing this on the branch The purpose of the I have run this workflow with a 500MiB test file twice, and twice it has failed (currently it is stalled on the second run and I am waiting for it to time out). I did a number of runs with a 100MiB file and saw one or two failures with about 10 successes. It seems a larger file is easier to trigger this failure. |
have the same issue here. |
I encountered this issue twice. |
@ligaz I never encountered this problem with v3 of the action. Only after upgrading to v4 did I start to see this issue. I have not tried the |
I'm experiencing the same issue on the |
I have just tried the macos-14 arm64 runners ( |
Interestingly, I just noticed one of my runs that stalled for 13 minutes, but started again and ran to completion. I don't think I've seen that before - I've had a hang sit there for two hours before I cancelled it.
|
I'm seeing sporadic upload failures lately too, on macOS runners only so far, and only for jobs uploading larger artifacts (around 400 MB). The weird thing is that the job shows up as failed, but the upload step is still running and doesn't show any error at all: E.g., here's a currently running workflow, with 2 upload failures for both macOS arm64 jobs (running on |
Got the same error with a self-hosted mac runner, consistently exactly 5 minutes after the step started. |
Same issue here with |
I think I can repro this 100% on both v3 and v4. I am using CMake and CPack to build the package. If the DragNDrop generator is used, then the subsequent upload-artifact step fails. I suspect this is because the DS_Store.scpt performs some UI work to set up the window and icon positions. My project is not yet open source, but it based heavily on cleanCppProject by kracejic, so you may be able to repro using that. I hope this helps - I have burned up a lot of my credit debugging this issue! EDIT: This is on a macos-13 runner |
Then that's a different issue. This issue only started happening with v4. But thanks for the input anyway - it will be useful to others if they hit the same problem as you. On this issue, for the github-hosted mac runners, I believe this is now fixed. I've been working with GitHub to get this resolved and the last round of changes to the runners has seen the issues resolved in my case - I have not had this hang for a week or two now, that I think I can say it is resolved for me. |
Copied from AiraForce project, in which the Mac package build actions/upload-artifact@v4 hangs. See actions/upload-artifact#527 (comment)
Thanks for getting back to me. I have been able to create a minimal repo to reproduce this issue and reported it at #573 |
I’m afraid I’ve been hit by this again. We have self-hosted Mac runner. We’ve switched to v4 last week and yesterday I’ve hit it again. Reverting back to v3 made the artifact upload successfully. Edit/Add exact build versions:
|
Uploading using v4 stuck twice recently Not using it until this issue is fixed actions/upload-artifact#527
actions/upload-artifact@v4 buggy on apple runners: actions/upload-artifact#527
actions/upload-artifact@v4 buggy on apple runners: actions/upload-artifact#527
What happened?
When I upload artifacts at the end of a build on a mac runner (
macos-13-xl-arm64
), about 1 time in 3, the upload stalls part way through and never completes. The job is eventually cancelled by GHA and my entire workflow is marked cancelled. I cannot restart that job as it is not marked as a failure.What did you expect to happen?
The artifacts upload to completion and the job finishes without error.
How can we reproduce it?
It is not easily reproducible. The workflows are private and cannot be shared here. I will open a support ticket to share more.
Anything else we need to know?
I have updated multiple workflows from v3 to v4 - all jobs in the workflow are using v4. I have 6 linux build jobs that all upload artifacts at the end. None of them have failed. For the mac builds, two jobs do architecture-specific builds and upload their artifacts. This has never failed. The final mac job takes the architecture-specific binaries and produces universal binaries. It is this job that has failed about 1 time in 3 when uploading the artifacts at the end. This failing job is typically always the last of the jobs to run. It necessarily runs after the two previous mac jobs, and the 6 previous linux jobs are quicker that the mac jobs and complete before.
The size of the failing artifacts is about 1.4G but on one run at least, it hung after logging the first 8MiB chunk.
All uploads for all the above-described jobs have:
The
path:
setting for the linux jobs is a single directory. Thepath:
setting for the working mac jobs is a single directory and a single exclude pattern. Thepath:
setting for the failing jobs is a single directory and three exclude patterns. Prior to uploading the chunks, the count of files to be uploaded is correct.The
overwrite:
setting isfalse
for all jobs.Output from one of the failed/stalled runs:
That is the end of the output for the step.
What version of the action are you using?
v4.3.1
What are your runner environments?
macos
Are you on GitHub Enterprise Server? If so, what version?
No response
The text was updated successfully, but these errors were encountered: