lifecycle icon indicating copy to clipboard operation
lifecycle copied to clipboard

mtimes on cache/build layers are squashed

Open dmikusa opened this issue 4 years ago • 2 comments

Summary

When you have a build tool that looks at the modification time of files to determine what needs to be built (in my case Rust's cargo), things get very weird if you try to cache the build artifacts with a cache=true layer.

I want to cache the output of previous builds to speed things up, but all of the mtimes on my build artifacts are overwritten with a single date. What ends up happening if I use a cache layer is that sometimes it rebuilds stuff that hasn't changed, sometimes it skips things that should be rebuilt and because it has lost the original mtimes on the files it's just not trustworthy at all.

I know that mtimes are changed for the purposes of reproducible builds and performance but I would request that we ease up this restriction a bit for certain cases:

  1. when the layer is launch=false (since this does not become part of the image)
  2. when the layer is launch=true and if the buildpack specifically indicates it requires undisturbed mtimes, possibly through the layer descriptor (i.e. opt-out when buildpack author accepts consequences like performance hit or reproducibility hit, in favor of maximum compatibility with installed tools)

Reproduction

Steps

It can be reproduced with the Rust CNB, but there isn't a version that is publicly available because it is totally broken.

Current behavior

Timestamps to files written to a build=true && cache=true layer are squashed.

Expected

Timestamps to files written to a build=true && cache=true layer to be retained.


Context

lifecycle version

Latest.

platform version(s)

All

anything else?

N/A

dmikusa avatar Apr 13 '21 18:04 dmikusa

@ekcasey - FYI only.

dmikusa avatar Apr 13 '21 18:04 dmikusa

Summarizing discussion from sub-team sync:

  • We think this is a good idea. It would require an RFC.
  • Open questions at this point: should it be opt-in?
  • There is a possible workaround where buildpacks could keep track of a timestamp to touch files with before they start the build. But this is a burden for buildpack authors, results in long labels on the image, and breaks reproducibility.
  • We noted that reproducibility of the cache is not as critical as for the image.

natalieparellano avatar Apr 29 '21 16:04 natalieparellano