New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crio embeds build #3702
Comments
|
For some reason, the "BuildDate" is in the API: https://github.com/kubernetes/apimachinery/blob/master/pkg/version/types.go#L28 It could still be faked (zeroed) instead, I suppose.
|
|
The best would be to make it (too) into a Then it would be easy to set it, just like DATE_FMT = +'%Y-%m-%dT%H:%M:%SZ'
ifdef SOURCE_DATE_EPOCH
BUILD_DATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u "$(DATE_FMT)")
else
BUILD_DATE ?= $(shell date -u "$(DATE_FMT)")
endif |
|
would you like to submit a PR with the fixes you're describing @afbjorklund ? |
|
Oh no, I see that somebody has changed GIT_COMMIT in 720545f That means my cri-o build is wrong, it is now COMMIT_NO instead... |
I can do that, not using SOURCE_DATE_EPOCH myself (but I like the idea) |
|
The problem with calling For some reason it thinks it is in the cri-o git, while I am still building from a tarball... I'm sure the opensuse RPM has a similar issue ? (fedora had: #2923 (comment)) But maybe it ends up with https://build.opensuse.org/package/live_build_log/openSUSE:Factory/cri-o/standard/x86_64 |
|
It actually had SOURCE_DATE_EPOCH for a while: d1696ce -X ${PROJECT}/internal/version.buildInfo=${SOURCE_DATE_EPOCH} \
-X ${PROJECT}/internal/version.buildDate=$(shell date -u +'%Y-%m-%dT%H:%M:%SZ') \So the builds were still not reproducible... |
BUG REPORT INFORMATION
Description
While working on reproducible builds for openSUSE, I found that
when building the cri-o package, there were slight differences between each build.
See https://reproducible-builds.org/ for why this matters.
Steps to reproduce the issue:
Describe the results you received:
crio and crio-status binaries differed thusly:
Describe the results you expected:
It should be possible to get identical build results anytime. If a build timestamp must be kept, it can be normalized with
SOURCE_DATE_EPOCH. See https://reproducible-builds.org/specs/source-date-epoch/ for the definition of this variable.Output of
crio --version:1.18
Additional environment details (AWS, VirtualBox, physical, etc.):
openSUSE-Tumbleweed 20200427
The text was updated successfully, but these errors were encountered: