mostly i was wondering about the files in (buildro...
# general
p
mostly i was wondering about the files in (buildroot)/.cache i am not seeing any speedup in my builds whether those files are there or blown away.
w
which language is this?
p
scala mostly, some jvm dependencies
w
hm... the caches should definitely help run over run if there is a lot of compilation going on.
odd.
p
i notice time diffs when i do pants clean-all, blowing away the workdir
but not so much with what i’m guessing is the local artifact cache?
or build cache, not sure which it is exactly
w
if there is one cache that is worth leaving on, it's the cache for compilation. but do see the note in https://www.pantsbuild.org/orgs.html#continuous-integration about turning off incremental compile in CI: incremental compiles are not cached by default.
p
yep, i’ve already added that change
out of curiousity, is there a best practice for the coursier cache management with pants? it’s getting upwards of 2GB now for my project and when I clear and rebuild it’s down to 500MB
the reason i’m looking into this is that cache restore/save for circleci for my project is taking ~5minutes for the ~/.cache/pants and (buildroot)/.buildcache directories (which are approx 4.8GB)
w
the
.buildcache
directory can be pruned using last modify or last access time
~/.cache/pants
is... a bit less formalized, unfortunately. some of the subdirectories can be pruned with modify/access time, but others cannot.
i think that the coursier directory is safe to prune using last modify / access time
p
ok, and when you say prune, you mean using
find -mtime
bash commands, rather than pants flags goals?
w
but if you confirm via the coursier docs, i'd love to hear about it 😃
yes, unfortunately.
p
yeah, i will. so far i haven’t found much from the coursier docs about cache management
ok, thanks! that clears up a lot for me
w
we're headed in a direction where pants can better manage its cache itself (basically: everything will be migrating under
.cache/pants/lmdb_store
, which is something that we can definitely GC)
p
is there an issue to watch/follow/comment on that project?
w
not really, no. it's a much, much larger effort to port tasks from the v1 Task API to the v2 Rule API.
p
ok. thanks again for all the clarification