Skip to content
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

Post-Cache Step Taking 150s in 2.7.2 Compared to 11-12s in 2.7.1 #182

Closed
cwfitzgerald opened this issue Jan 11, 2024 · 3 comments
Closed

Comments

@cwfitzgerald
Copy link

cwfitzgerald commented Jan 11, 2024

Howdy, thanks for this awesome tool!

Update

This is definitely an upstream problem with node20 - actions/toolkit#1578

Previous

Over at wgpu we started getting 2.7.2 of rust-cache and our "post cache" jobs started taking ~15x whenever there was any uploading to do. I have a hunch this isn't a problem with rust-cache but with the core github cache action this is calling off to, but I wanted to start here to see if we came to the same conclusion.

If you look at the logs (full log and post caching step.txt) I notice something suspicious with the timestamps:

2024-01-11T01:02:02.0366871Z ##[debug]Resource Url: https://acghubeus1.actions.githubusercontent.com/47bmaT25aAULNry7IX2PPcgYgwfrUqs3OBXgjQ0s8nspxqRVT2/_apis/artifactcache/caches/25694
2024-01-11T01:02:02.3201632Z Cache saved successfully
2024-01-11T01:04:12.6998275Z ##[debug]Node Action run completed with exit code 0
2024-01-11T01:04:12.7001105Z ##[debug]Finishing: Post caching

There's a 2 minute and 10 second disparity between the "cached saved successfully" log, and the debugging of github actions saying that node is finished. If I pin rust-cache to 2.7.1, this goes away.

My understanding is that "cached saved successfully" comes from the github cache code, not this code, so I am thinking it may be a problem there, but am curious what you think.

noaione added a commit to noaione/tosho-mango that referenced this issue Jan 11, 2024
There's an issue with rust-cache being slow:
Swatinem/rust-cache/issues/182
@Swatinem
Copy link
Owner

Thanks for reporting this and also providing a link to the upstream issue. Looks like there is a workaround, which I will integrate as well :-)

@Swatinem
Copy link
Owner

I published 2.7.3, hope that helps. I added the same process.exit() workaround as was mentioned in the upstream issue.

Please reopen if this problem still persists.

@cwfitzgerald
Copy link
Author

Seems to work well! About 100ms from the end of caching to the "end of job" message

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants