@witty-crayon-22786 - seems that caching

~/.cache

wasn't the problem, it happened again on a clean build

@adventurous-art-72916 : i think it's the other way around. you can end up with a bugged entry in

~/.cache

once you have a good entry there, you won't experience it again

other than the code itself, what else is part of the cache key computation in pants? the use case I have is we: 1) prebuild an AMI, in which it checks out a pants repo, and does complete build (

./pants compile ::

) 2) launch an instance using that AMI, do a git pull, and do another compile 3) do another compile on that launched instance what we’re testing now is when the git pull is a noop, that is AMI has same version of code as latest, then part (2) pants build should be instant. instead we’re seeing a lot of things still run, like ivy resolution, some compilation, webpack, etc. part (3) is always instant, that is once pants runs once on that particular box then another run is quick. so back to my question, is there something that would change on each instance (for example, every time we launch its a different IP), that would create this problem?

are you seeing cache hits or cache misses?

this is with a remote cache?

no local

when we build the AMI we actually compile the code there

and then snapshot

so there’s a whole

.cache

.pants.d

etc directory already there

ok. are you seeing cache misses?

and if so, which tasks are missing?

for example - https://gist.github.com/nitay/4e203b81b43409f20c57d688439e0132

whereas part (3) looks like https://gist.github.com/nitay/e0ad5bb5e16a349a37f8937666352587

is ivy the only task that is missing?

i think webpack also reruns, one sec i told my guy who’s looking into this to join the channel he’ll have more info

while he’s coming, related question, does running binary/bundle do any invalidation?

thats the goal we actually use - bundle

binary/bundle will use the cache for some things, but not for everything

but they won’t invalidate the cache in any way right

no.

i wouldnt expect them to, just checking

k

if you open up

./pants server --open

and expand a particular run, you can see cache stats

but that is for tasks that use the cache... they don't all use the cache.

@witty-crayon-22786 - @quiet-ice-72984 is the one on my end looking into this - @quiet-ice-72984 (see context above) - stu is asking if its only ive.resolve that’s getting cache invalidated, I said also webpack right

i was asking what things are missing the cache: different question

yep saw webpack get invalidated too. just for some context, what i did was: 1. full

./pants bundle

on a machine, success 2. snap that AMI 3. restore that AMI on a diff machine 4.

./pants bundle

without really touching anything 5. See this:....

And in general it didnt run like a "no-op", it did many things