other than the code itself, what else is part of t...
# general
m
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?