search

GoogleContainerTools / kaniko

Build Container Images In Kubernetes
Apache License 2.0
14.82k stars 1.44k forks source link

Image layer creation date not set #699

Open xcaliburinhand opened 5 years ago

xcaliburinhand commented 5 years ago

Actual behavior When an image layer is created, the created date is not set and defaults to the earliest possible date

"v1Compatibility": "{\"id\":\"8acba5ad9e92e5556c3fd964d1565c6d3f763e93d55b3dfe2cb6c64d2809d274\",\"parent\":\"2bea12fd7b0cf20cd4cf10a001796e83cbf4070c70c63768c5c93bfba2a743b4\",\"created\":\"0001-01-01T00:00:00Z\",\"container_config\":{\"Cmd\":[\"CMD [\\\"/bin/sh\\\"]\"]},\"author\":\"kaniko\"}"

Expected behavior The value for created is the time the layer was created

To Reproduce Steps to reproduce the behavior:

  1. build with kaniko & push to registry
  2. read manifest on registry

Additional Information Using executor:v0.9.0

Per the godoc at: https://godoc.org/github.com/google/go-containerregistry/pkg/v1#History it appears the v1.History key Created needs to be used.

Potentially add Created: v1.Time{Time: time.Now()}, to the v1.History block in build.go saveSnapshotToImage and push.go pushLayerToCache (I am not 100% familiar with Go syntax, so this may be slightly incorrect)

tejal29 commented 5 years ago

I think this is by design. We want cache the layer and adding a timestamp might change it. But that said, i think we need to fix our caching to not ignore the timestamp.

Thanks Tejal

claudioweiler commented 4 years ago

This behaviour still exists.

Could it occurs only when cache flag is used?

Could it occurs only when reproducible flag is used?

malcolm-s commented 3 years ago

We have this issue (creation date of 1970) when using the --reproducible flag.

But I think there might be a timestamp related issue anyway because if we use kaniko to rebuild with an identical context it produces an image with a different hash. I've not been able to track down what this difference is using dive or container-diff.

nlnjnj commented 3 years ago

/kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $HARBOR_REGISTRY/develop/psycho:$CI_BUILD_TAG reproduced this issue (creation date 1/1/01, 8:05 AM) when using above command

image:
    name: gcr.io/kaniko-project/executor:debug
cprivitere commented 3 years ago

This is causing major issues when paired with GitOps tools like flux and expecting it to auto build new images. The empty timestamp is treated as though nothing is new and thus no new image is created.