-
Notifications
You must be signed in to change notification settings - Fork 42
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
setup-grade action: Consider using D: drive on Windows Runners to address performance issues #290
Comments
Thanks for pointing out this issue and the recommendation. Yes, this would be a breaking change because workflows may already be bound to the current Gradle User Home location. Have you found the above workaround to make a significant different to performance? |
Adding in the above snippet took a GH build w/ a small-ish Gradle (really just a few custom plugins for versioning as the main build on this one was dotnet) from an erratic 9-20m to consistent 5-6m. |
This (from kotest) is perhaps a more reliable approach - using a link for |
Related: setup-action 3.5.0 has the new super-fancy cache-cleanup (which works amazing btw, previous cleanup wasn't catching old gradle distributions etc, nice and clean now). That enhancement downloads (or restores from GH cache) the latest stable Gradle distribution; it stores this under the user home, which on Windows runners is on the Very Slow C: drive (a lot of the latencies noted above were from restoring multiple gradle distributions from cache). Should likely be in
|
@cloudshiftchris I'm not sure that |
Fixing #270 will somewhat mitigate the performance overhead added by provisioning the latest Gradle as part of cache-cleanup. |
Below are all the env vars for
Arguably the Gradle install for cache cleanup is temporary/transient - it's internal, for that sole purpose. Likely should either be in a temporary dir, or homed alongside other stuff in
|
@cloudshiftchris I've implemented the fix to use If you could test it out using |
@bigdaz thanks for churning through everything in 4.0! Have tested out 4.0.0-rc.1 - after removing previous D: workaround and dropping in 4.0.0-rc.1, happy to report that all is well - everything ran as expected, the performance gains remained, the log out put confirms that GRADLE_USER_HOME is set on D:. |
Thanks for trying it out. I'll likely let the RC soak for a couple of weeks before pushing a |
On GH Windows runners there are known limitations with the performance of the C: drive; for tasks that write large amounts of data (Gradle caches) the performance at times can have multi-minute delays.
Other setup actions, such as setup-go and setup-dotnet already use D: drive to workaround this.
Users can workaround this (if they know to do so) by:
Proposing that the
setup-gradle
action set GRADLE_USER_HOME, if not already set, to a location under d:/a. This is perhaps a breaking change in behaviour (it invalidates the gradle user home cache entirely, starting from scratch), so perhaps an opt-in until next minor release.The changes in setup-go relating to this are here: https://github.com/actions/setup-go/pull/393/files
The text was updated successfully, but these errors were encountered: