https://kotlinlang.org logo
Join Slack
Powered by
On GitHub actions, setting up Gradle via `gradle/a...
# kotest-contributors
o
On GitHub actions, setting up Gradle via 
gradle/actions/setup-gradle@v3
is remarkably slow, particularly when running on Windows ( 9 minutes)>. Any idea why this happens and how it could be improved?
Trying a fix...
Seems like the GH Windows runners have a slow 
C:
drive which is used to store Gradle caches. I'm now trying with 
GRADLE_USER_HOME
set to 
D:\.gradle
on Windows. That seems to have an effect (starts with an empty cache, so setup time is now just 8 seconds), but I still have to convince the mechanism to save and re-populate the caches. If someone has an idea...
While Gradle itself honors 
GRADLE_USER_HOME
, of course 
gradle/actions/setup-gradle
does not. Its Typescript code invokes 
java
to report the system property 
user.home
when deciding where to put its caches. And 
java
ignores the 
HOME
environment variable for 
user.home
. Otherwise things would have been way too easy. 😵‍💫
a
Would adding 
-DsystemProp.user.home=D:/
to the Gradle commands on Windows work?
oh, no, TypeScript calls Java blob thinking upside down
time for a new issue for the Gradle GitHub action?
I saw you're working on making the Eventually tests stable - I'm investigating the stability of those too, and I want to use the coroutines test TimeSource to make it use virtual time, like I did for the 'retry' tests https://github.com/kotest/kotest/pull/4101
o
I have solved the cache location problem with a symbolic link. Now setup-gradle takes 50 seconds instead of 7+ minutes. Could file an issue for them as well, of course. I’d be happy for you to take over the timing issues with virtual time. Have thought about that as well. Should I revert my timing fixes before merging my PR or leave them as they are now? I’d like to clean up a bit before merging.
a
nice!
you can leave them as they are, and let's update them to use virtual time in another PR
o
OK. Would it benefit you if we merge my one quickly?
a
your PR only has one change to the 
continually
tests, so that's fine, it doesn't conflict with my draft https://github.com/kotest/kotest/pull/4109
and your PR also has changes to 
eventually
, which I haven't touched yet, so no problems there
so, no rush, but it'd be best if your PR didn't make a lot of changes to the non-deterministic tests, and we tackle their stability in other PRs
o
Cool. I promise not to touch anything else and focus on getting merged what’s already there. Hopefully we can have a successful merge to master soon so that snapshot builds get created again.
a
great!
o
All green now. 🙂
3 Views
Open in Slack
PreviousNext
Powered by