https://pantsbuild.org/ logo
Join Slack
Powered by
So after merging in main, I'm seeing the JVM tests...
# development
b
So after merging in main, I'm seeing the JVM tests take a really long time for trivial tests. I haven't verified, but I'm like 95% sure that this must be Coursier bootstrapping on every single test run, presumably because it's now being configured to use a hermetic cache directory instead of the default home directory cache. Was this deliberate? If so, do we plan to revert this behavior once we solve the locking issue?
f
It was. @witty-crayon-22786 should weigh in since he landed the change.
w
It shouldn't bootstrap on every run: the cache is sharded in tests, so there are #numcores copies. So once those N copies are populated on your machine, it should be equivalently fast.
But yea: once the coursier issue is fixed, we can stop sharding: can search for the coursier issue number in the code for the TODO
b
How big is N? I'm seeing it download every single time AFAICT during local iteration
w
Look in ~/.cache/pants/named_caches/tests
@bored-art-40741: oh, but if you have new code, make sure that you are using both of the methods of JdkSetup: take a look at modern examples of using it.
both 
jdk_setup.args
and 
jdk_setup.append_only_caches
without the latter, caches will be written into the sandbox but then lost.
(better ways to avoid that footgun would be welcome!)
f
we should probably introduce a 
JdkProcess
type that handles that under the hood with a conversion to 
Process
💭 1
b
Ahh, yeah, that was like the issue. Thanks Stu
w
@fast-nail-55400: yea, possibly. that or a 
jdk_setup.process(..)
helper method. might depend whether we expect the Process constructor params to continue to differentiate themselves.
Open in Slack
PreviousNext
Powered by