Timestamp of files from Cache and Workspace are at time of unpacking

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?

Is this a reasonable/feasible feature request?

1 Like

I would love for this to be the case.

SBT also uses timestamps and Scala is infamous for its long build times.

Good tip about using tar, maybe I can use that as a workaround for now.

Also keep in mind that if you are copying files then to use cp -p to preserve file attributes.

Hmm I just SSH’ed to the build machine and saw that the timestamps in the attached workspace look like they were preserved.

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

@vastopa

Thank you so much for the piece of advice.

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 :slight_smile: being of no help at all

Is it going to work if I compress the cache w/ e.g. zstd before pushing it?