22

I've tried to use buildpack in a maven project with Spring Boot 2.3.0 running:

mvn spring-boot:build-image

Image was created just fine, but I see the following info for it:

REPOSITORY                                    TAG                     IMAGE ID            CREATED             SIZE
gcr.io/paketo-buildpacks/builder              base-platform-api-0.3   daceb4f909b7        40 years ago        690MB
myimage                                       master                  a482a4a34379        40 years ago        285MB

Why does it say the image (along with the builder) was created 40 years ago?

Aleksandr Erokhin
  • 1,904
  • 3
  • 17
  • 32
  • Found this in buildpacks repo: https://github.com/buildpacks/rfcs/pull/50/files with link to https://reproducible-builds.org/docs/source-date-epoch/ . Still not sure how it's related to building an image. – Aleksandr Erokhin Oct 25 '20 at 17:04

2 Answers2

12

This is by design. In order to create reproducible builds (i.e. so that layers can be reused) the buildpack must create layers with a fixed time stamp. Otherwise, you wouldn’t be able to reuse the layers you created in previous builds because they would have different time stamps.

codefinger
  • 10,088
  • 7
  • 39
  • 51
  • 3
    Aren't layers reused based on hash? I don't understand really what it has to do with timestamp and why real one couldn't be specified. Could you please elaborate? – Aleksandr Erokhin Oct 25 '20 at 16:44
  • 1
    The timestamp of a file changes the hash. Many of the next-gen container builders (buildpacks, jib, ko) use fixed, not-quite-zero timestamp values to guarantee image reproducibility – codefinger Oct 26 '20 at 17:31
  • 14
    This is anything but "expected". It seems the builders couldn't figure out how to create effective hash, and instead resorted on a fake timestamp. – Abhijit Sarkar Nov 16 '20 at 09:26
  • This is what many other tools do (ko, jib, etc). Explained here: https://medium.com/buildpacks/time-travel-with-pack-e0efd8bf05db – codefinger Nov 17 '20 at 19:19
  • 10
    While it is true that other tools also offer this option, they of course also offer the option to use the current time, because this is what most people will expect. When using Quarkus out of the box (which uses jib), we get the expected current timestamp. When replacing docker builder with jib in spring boot, we may set creation time to USE_CURRENT_TIMESTAMP and get the desired result. How about supporting that as well in buildpack? – malamut Mar 02 '21 at 10:47
  • 1
    I agree with malamut - it certainly does seem like what anyone would expect - why should a hash change with the timestamp of a file - taking the date into account doens't seem like a sound design for a hash... – IARI Apr 26 '21 at 15:47
  • I probably should have used a better word. I've changed this to "by design" – codefinger Jun 23 '22 at 14:41
  • Pack already supports this feature: `--creation-time string`. Accepted values are Unix timestamps (e.g., '1641013200'), or 'now' -- source: https://github.com/spring-projects/spring-boot/issues/28798#issuecomment-1248078882 – silveiralexf Dec 12 '22 at 08:30
  • Any updates on this? Is it possible to alter that behaviour so that the correct timestamp is used? – Walnussbär Feb 03 '23 at 15:35
  • I'm trying a lot of things, even adding tasks.named("bootBuildImage") { def currentDate = new Date().getTime() environment['SOURCE_DATE_EPOCH'] = currentDate.toString() } but the image is still created in 1980. – Hugo Dias Feb 15 '23 at 11:23
4

In the new version you can set it. Hier is the gradle example

bootBuildImage {
      imageName = "docker.io/ringo"
      createdDate = "now"
}
kozla13
  • 1,854
  • 3
  • 23
  • 35