Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Images created by pack have a created timestamp of 40 years ago #931

Closed
simon0191 opened this issue Oct 30, 2020 · 4 comments
Closed

Images created by pack have a created timestamp of 40 years ago #931

simon0191 opened this issue Oct 30, 2020 · 4 comments
Labels
type/bug Issue that reports an unexpected behaviour.

Comments

@simon0191
Copy link

Summary

I created 2 images with pack. When I ran docker images it says that both images were created 40 years ago

Reproduction

  1. pack build test_image:test_1 --path . --builder heroku/buildpacks:18 --buildpack heroku/nodejs --buildpack heroku/ruby
  2. docker images
Current behavior
REPOSITORY               TAG                 IMAGE ID            CREATED             SIZE
heroku/buildpacks        18                  c5d37d5cbc47        40 years ago        1.4GB
test_image   test_1              c86b28114793        40 years ago        3.98GB
Expected behavior
REPOSITORY               TAG                 IMAGE ID            CREATED             SIZE
heroku/buildpacks        18                  c5d37d5cbc47        1 minute ago        1.4GB
test_image   test_1              c86b28114793        1 minute ago        3.98GB

Environment

pack info
Pack:
  Version:  0.14.2+git-0fd189d.build-1450
  OS/Arch:  darwin/amd64

Default Lifecycle Version:  0.9.1

Supported Platform APIs:  0.3, 0.4

Config:
(no config file found at /Users/simon/.pack/config.toml)
docker info
Client:
 Debug Mode: false

Server:
 Containers: 3
  Running: 2
  Paused: 0
  Stopped: 1
 Images: 24
 Server Version: 19.03.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.19.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 3.848GiB
 Name: docker-desktop
 ID: ZZTS:YKMV:4UNJ:PDLD:UFGL:VVDE:XRJY:ZALD:5DKP:P6KK:CSXJ:5DCP
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 63
  Goroutines: 71
  System Time: 2020-10-30T12:21:35.6309141Z
  EventsListeners: 4
 HTTP Proxy: gateway.docker.internal:3128
 HTTPS Proxy: gateway.docker.internal:3129
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine
@simon0191 simon0191 added status/triage Issue or PR that requires contributor attention. type/bug Issue that reports an unexpected behaviour. labels Oct 30, 2020
@dfreilich
Copy link
Member

Hi @simon0191 , thanks for the report! This is a feature, not a bug. We purposefully set the creation time of all layers to a standard date, in order to ensure that builds are repeatable. In simpler terms, we want to ensure that the application is the exact same, if the inputs (the builder, stacks and application) are the same, and in order to do that, we zero out the date (which makes it seem like it's 40 years old).

This is discussed a bit more here: #130 (comment)

We ended up writing all file times at January 1, 1980 00:00:1. This is because zip files (jars) use MS-DOS format for their file times and the epoch for those is Jan 1, 1980. This prevents a cascading failure with the JDK as noted here: https://bugs.openjdk.java.net/browse/JDK-8184940
Additionally, we wanted to stick to a known date and time for all files with an aim towards reproducible builds.

@dfreilich
Copy link
Member

@Muschke
Copy link

Muschke commented Apr 4, 2022

Hi Dfreilich, It is strange you call it a feature. You could still recalculate the creation date easily if that would be your problem.

@natalieparellano
Copy link
Member

Just FYI, planned changes to pack (#1281) would allow the image create time to be configurable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug Issue that reports an unexpected behaviour.
Projects
None yet
Development

No branches or pull requests

5 participants