The new JVM tests are flaking pretty regularly, ab...
# development
h
The new JVM tests are flaking pretty regularly, about 5-10% of builds if I had to put a number on it. Okay if I turn them off until @bored-art-40741 or others have a chance to stabilize?
w
yea, let’s do it.
will be some combination of more retry and more caching to fix it, and not sure about the precise mix.
i don’t think that we punch a hole through to share the
named_caches
for integration tests, but… maybe we should.
f
what parts of the test are flaking?
jar downloads?
h
Yeah
b
Sgtm, sorry been out the last week
I’ll be taking a look at this over the next few days
Okay, taking a look at this today. First and foremost--any tips on actually debugging issues like this where it only reproduces on CI? If it's the case that this is just inherently difficult to unit test on our CI, do we have a notion of heavier-weight, more flaky integration tests that don't necessarily run on every PR but run periodically and can be used to bisect regressions?
I'm actually wondering if the best next move here is to open a bug against Coursier, since we have a few example stack traces, we can theoretically generate repros if needed, and it seems to me like this is likely an issue with their locking/caching, or at the very least a UX issue with the error that's surfaced
h
Yeah I think that makes sense to open a bug. Perhaps offer that they can close of course if they don't think the issue is with them
b
sg, will do that today
In the meantime, I have a very hacky "fix" out for review that I hope will allow us to limp along CI testing for javac until the root cause is fixed: https://github.com/pantsbuild/pants/pull/12425
👍 1