Other than ~ rustup ~ cargo and src rust engine target what

Question

Other than ~ rustup ~ cargo and src rust engine target what else might I need to cache to prevent recompiles of rust code I m caching all of those but a rebuild of src rust is still triggered although not a rebuild of 3rdparty code

fast-nail-55400 · Answer

```Cache hit occurred on the primary key Linux cargo 2d8a03e3b927b43ef3be66d8e269421445c5265ccdc141995ba7b479f73a2341 baf3ca8bd24669a1db3e68e42d97300c2e3ec008a55a5509e18c63c86371e95c not saving cache ``` for Post Cache Cargo <https github com pantsbuild pants runs 1894209575 check suite focus=true step 18 2> is it in fact saving the cache

happy-kitchen-89482 · Answer

It is ~ cargo hasn t changed after the build so it doesn t re store it

happy-kitchen-89482 · Answer

That s all that means

happy-kitchen-89482 · Answer

And that I assume is why only the firstparty code is rebuilt the 3rd party code is fulfilled from that cache

happy-kitchen-89482 · Answer

But I assumed caching `src rust engine target ` would take care of that and apparently not

fast-nail-55400 · Answer

maybe dump the files going into the cache e g with `find` and then see if the same set of files is unpacked in the subsequent run assuming there is a way to make a file with the listing from the CI run into an easily accessible artifact <https config travis ci com ref job addons artifacts>

fast-nail-55400 · Answer

also maybe verbose output for the cargo rustc run to see if it will log why it is compiling something

happy-kitchen-89482 · Answer

I printed out the du h and it looks like all the dirs are restored correctly at least by rounded sizes

happy-kitchen-89482 · Answer

Verbose output is a good idea

fast-nail-55400 · Answer

also maybe check `Cargo lock` for any diff

fast-nail-55400 · Answer

also given <https github com rust lang cargo issues 4961 issuecomment 359189913> set env var `RUST LOG=info` and it should print out why it was invalidating

average-vr-56795 · Answer

Cargo currently uses mtime as its cache key and git doesn t preserve mtime on clone

average-vr-56795 · Answer

So first party code will always currently re compile because of this There s an issue in `cargo` to use content instead of mtime as the key but it s a fairly big change

average-vr-56795 · Answer

It s possible that you could hack together some kind of record the mtime of files and alter their mtime before building them script if you wanted Or to make cargo do content based caching or to make a pants ruleset which can be smarter than cargo

average-vr-56795 · Answer

Third party code will be being cached because the cache volume where they re stored will presumably preserve timestamps adequately

average-vr-56795 · Answer

See also <https github com rust lang cargo issues 6529>

happy-kitchen-89482 · Answer

aha that is exactly it Thanks < average vr 56795>

happy-kitchen-89482 · Answer

That would have taken me forever to figure out

happy-kitchen-89482 · Answer

OK this is not worth working around it ll have to wait until Pants has Rust support which can a you say be smarter than Cargo