Propagate SOURCE_DATE_EPOCH from the client env #1482
Conversation
|
Could we do it also on |
build/build.go
Outdated
| @@ -579,6 +579,13 @@ func toSolveOpt(ctx context.Context, node builder.Node, multiDriver bool, opt Op | |||
| } | |||
| } | |||
|
|
|||
| // Propagate SOURCE_DATE_EPOCH from the client env | |||
| if v, ok := os.LookupEnv("SOURCE_DATE_EPOCH"); ok { | |||
There was a problem hiding this comment.
I think this should be ok && v != "" as SOURCE_DATE_EPOCH= could be a common way to reset the behavior.
There was a problem hiding this comment.
To support SOURCE_DATE_EPOCH=, the condition cannot contain v != "" IIUC
There was a problem hiding this comment.
wdym? I'm thinking of the case where environment has SOURCE_DATE_EPOCH defined but the user doesn't want to forward it to the buildkit(user wants buildkit to just use the current time). What should they set?
There was a problem hiding this comment.
When the Dockerfile already has ARG SOURCE_DATE_EPOCH=<non empty value>, I'd expect export SOURCE_DATE_EPOCH= to set the build arg to an empty string.
There was a problem hiding this comment.
Dockerfile defining SOURCE_DATE_EPOCH is only one possibility. The user might just want to control the timestamps in the config metadata and not the RUN commands.
AkihiroSuda
force-pushed
the
auto-propagate-source-date-epoch
branch
from
5bd49ef
to
e1ae109
Compare
updated |
AkihiroSuda
force-pushed
the
auto-propagate-source-date-epoch
branch
from
e1ae109
to
58d644f
Compare
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
AkihiroSuda
force-pushed
the
auto-propagate-source-date-epoch
branch
from
58d644f
to
0e6f5a1
Compare
|
I guess we can safely backport this to buildctl too: |
See https://reproducible-builds.org/docs/source-date-epoch/
Expected to be used with BuildKit v0.11 or later (https://github.com/moby/buildkit/issues?q=label%3Aarea%2Freproducible-builds+)