When I attach a workspace or restore a cache, the modified timestamp on the files in the directory I’m unpacking gets the timestamp from when the attach/restore step is performed.
My CI pipeline is for iOS, and the Xcode build system determines when to recompile files based on it’s modified timestamp. This forces a fresh/clean build on every commit and due to the size of the project that is building, the build times are very long.
If the modified timestamps can be preserved, this would enable incremental builds for iOS which would significantly reduce our build time (and I’m sure many others).
I’m hoping to be able to define a parameter or env var which would allow me to choose to preserve this timestamp. I know for tar this is possible with an optional parameter --atime-preserve[=METHOD]. Perhaps this is also possible for the caching mechanism CircleCI uses?
Actually this is not what this option does. This option only prevents the atime of the file being put into the tar from being modified, not the files that are dumped from the tar.
Hey - thanks for replying! I should have closed this issue when I got more information. You are right, the timestamp is preserved. It’s actually xcodebuild system which is shaving milliseconds off timestamps. You can refer to the following bug for more info on it: https://bugs.swift.org/browse/SR-11760
I tried to build AOSP but there is no way it’s gonna finish in 5 hrs. Then I set up branch build-A which builds on a 3h30min timeout then push the cache, and build-B to collect the cache then finish it (incremental build manner).
But it just starts all over again in build-B being of no help at all
Is it going to work if I compress the cache w/ e.g. zstd before pushing it?