Add mechanism for platform to provide image creation time #292
Conversation
Signed-off-by: Natalie Arellano <narellano@vmware.com>
platform.md
Outdated
| @@ -872,6 +872,9 @@ To achieve reproducibility the lifecycle SHOULD set the following to a constant, | |||
| - file modification times in generated layers | |||
| - image creation time | |||
|
|
|||
| The platform MAY set `SOURCE_DATE_EPOCH` in the lifecycle execution environment, where the value of `SOURCE_DATE_EPOCH` MUST be a [UNIX timestamp](https://reproducible-builds.org/specs/source-date-epoch/). | |||
| If `SOURCE_DATE_EPOCH` is set, the lifecycle SHOULD set the image creation time to its value. | |||
There was a problem hiding this comment.
I think setting just the image creation time is 👍
The primary use case I've seen asked from time to time is mostly around the management of the produced images locally or in a registry. The image creation time should be enough to allow for automation around cleanup and auditing of produced images.
I don't know that I've seen anyone reach out about the file mod times, but I would not be opposed to it either if someone felt strongly that we should honor SOURCE_DATE_EPOCH for the files inside the container as well.
There was a problem hiding this comment.
Assuming SOURCE_DATE_EPOCH changes fairly often, setting the file mod time would effectively prohibit launch layer re-use and make builds slower... maybe this is something we could add if someone asks for it, but since no one has, I agree we should leave it out for now.
There was a problem hiding this comment.
As the person who made the original Slack request, I can back up @jabrown85 here on the use case.
This request is purely about how container registries don't really let us separate metadata like timestamp from the artifact itself which makes them a huge pain to manage. The concrete example being that I can tell Gitlab to keep the last 50 images we made of our main branch, but if they all have the same timestamp, then it removes all but 50 random images, often including the one we have currently deployed in prod! So all tag management basically becomes manual or scripted in a janky way like "check the last 50 tags in the git history for that branch and then remove anything that's not that."
I'd rather have a faster build time than not, since it the file mod time doesn't affect the end pain point.
This would basically let us set this env in our CI for building main branch containers so those can be managed, but leave everything else getting the benefits of fully reproducible builds.
|
Is the only downside of this that it hurts reproducibility? Given the same source with no modifications the image/ref will change based on the timestamp? |
Signed-off-by: Natalie Arellano <narellano@vmware.com>
natalieparellano
force-pushed
the
source-date-epoch
branch
from
5fb5f47
to
d6060b7
Compare
| @@ -546,6 +546,7 @@ Usage: | |||
| | `<stack>` | `CNB_STACK_PATH` | `/cnb/stack.toml` | Path to stack file (see [`stack.toml`](#stacktoml-toml) | |||
| | `<uid>` | `CNB_USER_ID` | | UID of the build image `User` | |||
| | `<layers>/config/metadata.toml` | | | Build metadata (see [`metadata.toml`](#metadatatoml-toml) | |||
| | | `SOURCE_DATE_EPOCH` | | Timestamp for `created` time in app image config | | |||
There was a problem hiding this comment.
Though other variables used to configure the lifecycle start with CNB_ it seems better keep the interface consistent with other tooling (see under "Reading the variable" here).
|
Putting this in draft so that we can work through buildpacks/rfcs#204 |
|
Undrafting this as buildpacks/rfcs#204 is almost out of FCP. |
Signed-off-by: Natalie Arellano <narellano@vmware.com>
|
I've merged that RFC, so please look at this spec change please 🙏 |
To continue the conversation here.
See related imgutil PR: buildpacks/imgutil#137.