https://pantsbuild.org/ logo
Powered by
b

bored-art-40741

10/04/2021, 11:58 PM
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

fast-nail-55400

10/05/2021, 12:42 AM
It was. @witty-crayon-22786 should weigh in since he landed the change.
w

witty-crayon-22786

10/05/2021, 12:48 AM
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

bored-art-40741

10/05/2021, 12:55 AM
How big is N? I'm seeing it download every single time AFAICT during local iteration
w

witty-crayon-22786

10/05/2021, 1:48 AM
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

fast-nail-55400

10/05/2021, 6:29 PM
we should probably introduce a 
JdkProcess
type that handles that under the hood with a conversion to 
Process
💭 1
b

bored-art-40741

10/05/2021, 10:16 PM
Ahh, yeah, that was like the issue. Thanks Stu
w

witty-crayon-22786

10/05/2021, 10:19 PM
@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.
Powered by