https://pantsbuild.org/ logo
Join Slack
Powered by
Some Java-related flakiness in CI now, it looks li...
# development
h
Some Java-related flakiness in CI now, it looks like: https://github.com/pantsbuild/pants/runs/3683923284
f
I have a PR out to skip the Java tests
I say we give up on Coursier downloading the JDK and just have Pants manage that.
We would need immutable cache support to make it performant but we need that for Go as well.
h
... or we (at first) assume there is a JDK available on the path
f
Right, I just want to rely on system-installed JVM for near future.
But for a future where we manage the toolchain for user we will need to overcome the issue with unpacking large blobs.
But that future is not now.
h
So coursier can't cut it?
What is the underlying problem?
w
although the only one we’ve actually experienced is
Copy code
Extraction failed: java.nio.file.FileSystemException: /home/runner/.cache/coursier/jvm/.adopt@1.11.0-11.part/jdk-11.0.11+9 -> /home/runner/.cache/coursier/jvm/adopt@1.11.0-11: Directory not empty
afaik.
it seems like someone with some JVM/scala experience could dive in to help resolve that, but it’s unclear how soon it would make a release.
failing that, we could also take a heavy handed approach of wrapping coursier and applying a file lock on its entire named_cache directory.
h
Just checking that implementing ourselves wouldn't just land us with some version of the same issue
w
it’s honestly pretty surprising that this is buggy… it’s seemingly such a simple thing, and they have broken library functions for it. so: concerning.
but on the other hand, we know exactly how to avoid this kind of issue, so it’s unlikely that we would do it ourselves.
i continue to think that wrapping a tiny bit of bash around coursier would be enough to avoid this, and would have the advantage of bootstrapping a precise JVM to improve reproducibility.
Open in Slack
PreviousNext
Powered by