Rules_docker: Set creation time to be {SOURCE_DATE_EPOCH} when stamping is enabled

[mattmoor]

The release of google/containerregistry that we are on supports overriding creation_time, and I am adding stamping support to docker_build more broadly in https://github.com/bazelbuild/rules_docker/pull/154.

We should consider either:

1. Making {SOURCE_DATE_EPOCH} the default when stamp=True, or
2. Enabling users to specify a creation_time, which can be {SOURCE_DATE_EPOCH}.

[mattmoor]

@damienmg Is {SOURCE_DATE_EPOCH} supported at all now?

[mattmoor]

If I just tweak my PR to use this, I get:

<explosion>
KeyError: 'SOURCE_DATE_EPOCH'

So it definitely isn't in 0.5, maybe 0.6...? Is there an issue we can link this to to cover support?

[damienmg]

https://github.com/bazelbuild/bazel/issues/2240

On Wed, Sep 20, 2017, 7:32 PM mattmoor [e-mail] wrote:

If I just tweak my PR to use this, I get:

KeyError: 'SOURCE_DATE_EPOCH'

So it definitely isn't in 0.5, maybe 0.6...? Is there an issue we can link
this to to cover support?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_docker/issues/155#issuecomment-330924315,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADjHf0pO7R5bqMaRpFDjWbzB_fmzkbNdks5skUw5gaJpZM4PeNAF
.

[damienmg]

Also note that inside the volatile info text file it will always be BUILD_TIMESTAMP (not SOURCE_DATE_EPOCH).

[ixdy]

Bazel 0.9 uses SOURCE_DATE_EPOCH to set the BUILD_TIMESTAMP, so we might be able to look into using this soon?

[leifmadsen]

Just wanting to ping this issue, as I'm still seeing containers from 47 years ago, and it isn't clear how to override that (or if it can yet).

[mattmoor]

@leifmadsen I assume @ixdy is right, and once Bazel 0.9 cuts we can switch "stamped" docker builds to use this stamp variable in its timestamp.

[ixdy]

is anything still blocking us here? it seems like it should be safe to use BUILD_TIMESTAMP to set creation_time when stamping is enabled, right? Environments that want repeatable builds should be able to set SOURCE_DATE_EPOCH before calling bazel and have it do the right thing.

[mattmoor]

Nothing AFAIK.

[ixdy]

I think there might still be missing functionality - the language specific image rules (such as go_image) don't seem to timestamp properly.

[srikumar-b]

I still see unix epoch timestamp (48 yrs) for a bazel built docker image when I see it through docker image. I have verified with bazel v0.17.1, rules_docker v0.5.1
I have also set creation_timestamp manually and still dont see valid build timestamp for docker image. Am I missing something?

[nlopezgi]

I dont think there has been any work to get this working since matt's last comment in February (and have not kept up to date with changes in latest versions of Bazel wrt this issue). Given the comment above states the feature is in since Bazel 0.9, it should be a matter of fixing these rules to use the BUILD_TIMESTAMP to set creation time. However, working on this feature is not currently a priority for us, but I'd be happy to help review a PR if you want to send one! Reopening to leave clear this has not happened yet.

[srikumar-b]

@nlopezgi I thought https://github.com/bazelbuild/rules_docker/pull/364/files have added the required support. So whatever we see about using current_time = BUILD_TIMESTAMP and Stamp = True mentioned at https://github.com/bazelbuild/rules_docker#stamping are not working?

[nlopezgi]

The PR you point to does look like it should have added the support, but since you are reporting its not working for you (and the other comment from May that states "there might still be missing functionality") I do think its accurate to say that what is mentioned in https://github.com/bazelbuild/rules_docker#stamping is not working as intended. As I mentioned, this feature is not a priority for us, so wont get to fix anytime soon, but if you want to look into why its not working and send a PR to fix I'm happy to help.

[ixdy]

This appears to be working if you set stamp = True on container_images, though other rules (like go_image) seem to be lacking support still.

[nlopezgi]

Hi @ixdy, would either of the following work for your use case:

• using as base a container_image with stamp = True and then extending that in your go_image or,
• using as base container your go_image and then extending that with a container_image with stamp = True
  If both of these do not work, please let us know so we can try to figure out a solution.

[srikumar-b]

@nlopezgi I tried the first way i.e using as base a container_image with stamp = True and then extending that in your go_image which did not work.

container_image( name = "base", .... creation_time = "{BUILD_TIMESTAMP}", stamp = True, ) go_image( name = "container", base = ":base", .... visibility = ["//visibility:public"], )

[nlopezgi]

is this still an issue? please reopen if so.

[albttx]

@nlopezgi this is still an issue. i have the same configuration as @srikumar-b and my image are 49years old.

i'd love to have a correct timestamp.

Is this supposed to be fixed ?

[nlopezgi]

Hi @albttx,
No, it's not fixed, I just closed due to lack of activity. We're not planning on working on this feature atm, but would gladly work with you if you want to send a PR to implement it. Thanks for pinging this issue,

[mgenov]

With a minimal change (passing stamp from kt_jvm_image to jar_app_layer to container.image.implementation) I've made the following rule working as expected:

kt_jvm_image(
    name = "image",
    srcs = [
        "ServiceBootstrap.kt",
    ],
    layers = [
        ":lib",
        "@maven//:org_jetbrains_kotlin_kotlin_stdlib_jdk7",
    ],
    main_class = "ServiceBootstrapKt",
    resources = glob(["src/main/resources/**/*.*"]),
    stamp = True,
)

Would this change be acceptable as solution?

[mgenov]

Saw the comments in https://github.com/bazelbuild/rules_docker/pull/560 and it seems that preferred way by design would be base image to be used for this kind of attributes.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

[FlymeDllVa]

Ping :)

[gravypod]

@FlymeDllVa is the remaining issue that the support for providing a build timestamp is varied in the various language rules? If that's the case it would be very helpful if someone could open separate issues for the individual languages or just make a list of which rules diverge. This way it will be easy to see where the inconsistencies are.

We're still in the process of getting a PR ready to fix the tests at HEAD and are not yet merging changes to the code that effect the functionality of the rules. If we had this list together it could be something I could ready a PR for but I wouldn't expect this to be resolved quickly.

Also, is there a reason people need the ability to change the build timestamp of images? Having an understanding of the use case driving this feature would help prioritize things.

[FlymeDllVa]

To make it clear what is the most recent label in the registry, if the build goes by hash.

[gravypod]

@FlymeDllVa interesting. Would it be possible to, rather than modify the timestamps of the builds, stamp the timestamps while pushing images to the registry? Something where you can:

bazel run //:push_containers --to registry.scm.com/company --set_build_timestamp

I'd be worried that encouraging this will lead to very slow builds since, whenever the timestamp changes, you'd invalidate the cache of all of your images that use this feature. If this is purely a goal of a "release" activity we could put this logic/functionality into that tool so everyone's cache is preserved.