Hey again. What are the limitations of the test re...
# general
f
Hey again. What are the limitations of the test results caching? I'm thinking about 3rd party dependencies or internal dependencies in another repository f.e.? From a quick trial and error pants impressed me but still there must be limits, right?
e
What limits do you imagine? A test run is - in Pants parlance - a Process execution. The cache key is effectively a hash of
{"env": [...], "args": [...], "file_inputs": [...]}
where the file inputs are not the files themselves, but their fingerprints (hash + size).
The real files are cached (see
du -sh ~/.cache/pants/lmdb_store
) and those take up the most space, but if there were a way to selectively nuke cache entries, you could nuke all the files cached themselves and still hit the test process execution cache key.
f
I don't know - I guess the
"env"
part seems to be the most opaque to me ... everything available locally feels rather easy to grasp - if there is a change, it'll be noticed.
e
The env are the env vars.
f
oh ok ... then
"venv"
šŸ˜„
b
At a very high level, the exact versions/source-code of external dependencies (including git dependencies) influence the cache key: if they change, the cache key will change and thus tests will be rerun.
f
Ok that sounds reasonable - somehow challenging to implement I could imagine - but ok, I’m convinced I guess šŸ˜›