Use SOURCE_DATE_EPOCH to configure image create time #204

natalieparellano · 2022-02-24T22:17:20Z

Signed-off-by: Natalie Arellano <narellano@vmware.com>

buildpack-bot · 2022-02-24T22:17:38Z

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

(none)

jabrown85 · 2022-02-24T22:54:33Z

text/0000-source-date-epoch.md

+[unresolved-questions]: #unresolved-questions
+
+- What parts of the design do you expect to be resolved before this gets merged?
+  * Should we require users to be on platform api 0.9 in order to use this feature? (Opinion: no, because this feature is invisible if the environment variable is not set. The motivation for spec'ing this in the platform api is to make it clear for platform operators how to use it.)


I agree - no need to be on newer platforms to use it.

If we are not tying it to a specific platform API, I don't see why we should note this in the platform spec and not in our docs. It seems a weird that we are retroactively adding something to the past platform APIs but only documenting it for 0.9. I would be in favor of just documenting this in the lifecycle docs somewhere and implementing it in pack via a flag if we plan on introducing this for past platform APIs that have already been released as opposed to adding it to the platform spec.

We follow something similar with our estargz support in lifecycle.

I disagree that this shouldn't be part of the specification. As platform implementors, we rely on the API to know what parameters we can use especially when it has specific side effects on the outcome. estargz support is an accident and can't be documented as supported because of the similar.

Essentially platforms that don't get to select their lifecycle implementations but rely on what's on the builder go from saying "by doing X you get Y" to "by doing X you MAY get Y".

To the original opinion regarding backward compatibility, nothing on the specification says a lifecycle implementation CAN'T support an arbitrary environment variable.

Yes, but it very much violates the whole point of having a platform API. If we start introducing new features for older platform APIs, the platform is now dependent on a specific lifecycle version to support a specific feature rather than knowing the feature set it will have available given a platform API.

Say you are a platform implementing this feature in an older platform api and you set this environment variable. You as a platform will never know whether or not the lifecycle actually respected the variable and set an appropriate date for the image or not as the lifecycle has no such contract for older apis.

On the other hand if we explicitly implement this as part of a new platform api then there is an inherent contract that the platform can rely upon.

Yes, I agree. That's the argument I have for moving forward and having it spec'd so it makes sense. I guess I personally care less for prior implementations because it's a lower risk probability. Specially if it's not the conventional env var but something prefixed with CNB_.

the lifecycle has no such contract for older apis

Personally I think this is totally fine. The feature isn't mentioned in older platform apis, so it can't be relied upon. Use at your own risk.

I think we should spec the feature b/c it's existence determines whether a platform like pack can provide a new feature (a flag to use the real creation time) to users.

the platform is now dependent on a specific lifecycle version to support a specific feature rather than knowing the feature set it will have available given a platform API.

Whatever decision we make here, I still think the platform API is the source of truth.

With my platform author hat on, I basically see the decision to support this in old APIs as irrelevant. I won't trust that I can use it in an old API, but also it doesn't hurt me. Maybe there are some edge cases where having it is helpful. E.g. I operate a very specific platform that uses a specific builder and I know my lifecycle version, maybe I go ahead and use this feature without checking the lifecycle version? But I am only tempted if I control the environment and know what I am doing.

That was a very long winded way of saying "whatever y'all can agree on is fine with me on this one".

👍 on it being spec'd if we want it as part of the contract.

jromero · 2022-03-01T22:10:28Z

text/0000-source-date-epoch.md

+# Summary
+[summary]: #summary
+
+To allow for [build reproducibility](https://github.com/buildpacks/spec/blob/main/platform.md#build-reproducibility), images created by Cloud Native Buildpacks have a hard-coded create time of January 1, 1980. We have received requests from the community (see [here](https://github.com/buildpacks/pack/issues/1281) and [here](https://buildpacks.slack.com/archives/C94UJCNV6/p1643842965830459)) to allow for this value to be configurable. This RFC proposes making the value configurable by setting `SOURCE_DATE_EPOCH` in the lifecycle's execution environment during `export`.


I dislike that this environment variable doesn't align with the CNB_ prefix of all other environment variables. I get that it comes from a convention but I'm not sure that it justifies breaking away from our convention. Even ko has KO_DATA_DATE_EPOCH . What if we left SOURCE_DATE_EPOCH up to the platforms to decide support on but have CNB_DATE_EPOCH or something similar for the interface to the lifecycle?

IIUC KO_DATA_DATE_EPOCH is used for a slightly different purpose: "used to set the modtime timestamp of the files in KO_DATA_PATH". However jib uses USE_CURRENT_TIMESTAMP to set image create time.

What about an emoji vote?

🎉 CNB_SOURCE_DATE_EPOCH
❤️ SOURCE_DATE_EPOCH

I left both emojis to start the poll, but I am in favor of SOURCE_DATE_EPOCH. I think that one "wins" unless others come forward.

text/0000-source-date-epoch.md

hone · 2022-03-02T18:55:00Z

text/0000-source-date-epoch.md

+- Why should we do this?
+  Users have asked for it
+- What use cases does it support?
+  A meaningful image create time, e.g., the ability to determine which images are most recent


Don't we have a slack thread that describes in detail a use case for the most recent image like pruning old images.

Spec comment, Slack thread

ekcasey · 2022-03-04T22:23:19Z

text/0000-source-date-epoch.md

+# How it Works
+[how-it-works]: #how-it-works
+
+This [PR](https://github.com/buildpacks/imgutil/pull/137) to imgutil would read the environment variable at the point of saving the image. An alternative implementation could be to have the `exporter` read the variable and provide it via a new `SetCreatedAt()` method on the `imgutil.Image` interface. The latter might be safer as it would avoid unintended side effects for other consumers of imgutil (e.g., `pack`). 


The latter might be safer as it would avoid unintended side effects for other consumers of imgutil (e.g., pack).

As convenient as it would be to merge the existing PR, I tend to agree.

text/0000-source-date-epoch.md

ekcasey · 2022-03-04T22:43:28Z

text/0000-source-date-epoch.md

+[unresolved-questions]: #unresolved-questions
+
+- What parts of the design do you expect to be resolved before this gets merged?
+  * Should we require users to be on platform api 0.9 in order to use this feature? (Opinion: no, because this feature is invisible if the environment variable is not set. The motivation for spec'ing this in the platform api is to make it clear for platform operators how to use it.)


I think we should spec the feature b/c it's existence determines whether a platform like pack can provide a new feature (a flag to use the real creation time) to users.

the platform is now dependent on a specific lifecycle version to support a specific feature rather than knowing the feature set it will have available given a platform API.

Whatever decision we make here, I still think the platform API is the source of truth.

With my platform author hat on, I basically see the decision to support this in old APIs as irrelevant. I won't trust that I can use it in an old API, but also it doesn't hurt me. Maybe there are some edge cases where having it is helpful. E.g. I operate a very specific platform that uses a specific builder and I know my lifecycle version, maybe I go ahead and use this feature without checking the lifecycle version? But I am only tempted if I control the environment and know what I am doing.

That was a very long winded way of saying "whatever y'all can agree on is fine with me on this one".

natalieparellano · 2022-03-10T14:37:18Z

With 3/5 implementation maintainers in favor, I think this can be in FCP

Signed-off-by: Natalie Arellano <narellano@vmware.com> Co-authored-by: Emily Casey <ecasey@vmware.com>

natalieparellano · 2022-03-17T14:34:33Z

@sclevine @ekcasey can this be merged please? I can confirm that issues have been created.

[#204] Signed-off-by: Terence Lee <hone02@gmail.com>

hone · 2022-03-23T15:51:23Z

@natalieparellano I can do it.

Use SOURCE_DATE_EPOCH to configure image create time

1a9018d

Signed-off-by: Natalie Arellano <narellano@vmware.com>

natalieparellano added team/implementation scope/team RFC scoped to a sub-team as opposed to the entire project. labels Feb 24, 2022

natalieparellano requested a review from a team as a code owner February 24, 2022 22:17

github-actions bot assigned ekcasey and sclevine Feb 24, 2022

natalieparellano mentioned this pull request Feb 24, 2022

Add mechanism for platform to provide image creation time buildpacks/spec#292

Merged

natalieparellano requested review from ekcasey, jabrown85, sambhav and jromero February 24, 2022 22:19

jabrown85 approved these changes Feb 24, 2022

View reviewed changes

natalieparellano mentioned this pull request Feb 25, 2022

Open Use SOURCE_DATE_EPOCH to configure image create time buildpacks/lifecycle#809

Closed

jromero reviewed Mar 1, 2022

View reviewed changes

hone reviewed Mar 2, 2022

View reviewed changes

text/0000-source-date-epoch.md Show resolved Hide resolved

hone reviewed Mar 2, 2022

View reviewed changes

ekcasey approved these changes Mar 4, 2022

View reviewed changes

ekcasey requested review from sclevine and nebhale March 4, 2022 22:44

hone approved these changes Mar 9, 2022

View reviewed changes

natalieparellano added the Final Comment Period label Mar 10, 2022

Natalie Arellano and others added 2 commits March 10, 2022 09:37

Update text/0000-source-date-epoch.md

32ac0ed

Signed-off-by: Natalie Arellano <narellano@vmware.com> Co-authored-by: Emily Casey <ecasey@vmware.com>

Merge branch 'main' into implementation/source-date-epoch

a7514a3

hone added a commit that referenced this pull request Mar 23, 2022

RFC 0103

146bafd

[#204] Signed-off-by: Terence Lee <hone02@gmail.com>

hone merged commit 5d67be2 into main Mar 23, 2022

hone deleted the implementation/source-date-epoch branch March 23, 2022 15:51

schneems mentioned this pull request Oct 10, 2024

Investigate FIFO asset cache cleaner with Pack creation time behavior heroku/buildpacks-ruby#302

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use SOURCE_DATE_EPOCH to configure image create time #204

Use SOURCE_DATE_EPOCH to configure image create time #204

natalieparellano commented Feb 24, 2022 •

edited

Loading

buildpack-bot commented Feb 24, 2022

jabrown85 Feb 24, 2022

sambhav Feb 25, 2022 •

edited

Loading

sambhav Feb 25, 2022

jromero Mar 1, 2022

jromero Mar 1, 2022

sambhav Mar 2, 2022 •

edited

Loading

jromero Mar 2, 2022

natalieparellano Mar 4, 2022

ekcasey Mar 4, 2022

hone Mar 9, 2022

jromero Mar 1, 2022 •

edited

Loading

natalieparellano Mar 4, 2022

natalieparellano Mar 4, 2022 •

edited

Loading

natalieparellano Mar 15, 2022

hone Mar 2, 2022

natalieparellano Mar 4, 2022

ekcasey Mar 4, 2022

ekcasey Mar 4, 2022

natalieparellano commented Mar 10, 2022

natalieparellano commented Mar 17, 2022

hone commented Mar 23, 2022

Use SOURCE_DATE_EPOCH to configure image create time #204

Use SOURCE_DATE_EPOCH to configure image create time #204

Conversation

natalieparellano commented Feb 24, 2022 • edited Loading

buildpack-bot commented Feb 24, 2022

Issues

Choose a reason for hiding this comment

sambhav Feb 25, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sambhav Mar 2, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jromero Mar 1, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

natalieparellano Mar 4, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

natalieparellano commented Mar 10, 2022

natalieparellano commented Mar 17, 2022

hone commented Mar 23, 2022

natalieparellano commented Feb 24, 2022 •

edited

Loading

sambhav Feb 25, 2022 •

edited

Loading

sambhav Mar 2, 2022 •

edited

Loading

jromero Mar 1, 2022 •

edited

Loading

natalieparellano Mar 4, 2022 •

edited

Loading