Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
8238650: Allow to override buildDate with SOURCE_DATE_EPOCH #99
Allow to override buildDate with
This PR was done while working on reproducible builds for openSUSE.
Hi bmwiedemann, welcome to this OpenJDK project and thanks for contributing!
We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing
If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing
in order to make builds reproducible. See https://reproducible-builds.org/ for why this is good and https://reproducible-builds.org/specs/source-date-epoch/ for the definition of this variable. Signed-off-by: Bernhard M. Wiedemann <email@example.com>
https://www.oracle.com/technetwork/community/oca-486395.html#w now has
Thanks, somehow I had not got an email notification for that.
As an optional override, I am OK with the concept of having a way for the build to be reproducible.
FWIW, I have scripts that will unpack the modular jar files and diff each class as well as doing the same for a src.zip, and it's pretty easy to tell if only VersionInfo (which is the class that records the time stamps) has changed.
I note that in practice, this is useful for a certain class of builds (e.g., CI or nightly test builds), but each released build is necessarily going to be different because you want a unique time stamp and build number associated with it.
I will review this (probably some time next week) and would like @johanvos to review as well.
I agree that such specialized diff tools have some value, yet, there are also some limitations and downsides to them. E.g. you cannot simply tell another party what the expected sha256sum of a build result is.
https://www.suse.com/c/?p=42014 also has a section on problems with "the use of specialized comparison tools like [openSUSE's] ‘build-compare‘ "
I probably should write an FAQ entry about that topic...
For release builds, it is important that other people can take the released sources and reproduce the same original binaries with the same release number (and ideally same timestamps) to easily verify that the build was clean (not corrupted by bad CPUs/RAM/HDDs or someone messing with the build machine).
kevinrushforth left a comment
Finally getting to this (sorry for the delay). This seems OK to me, as it is not an intrusive change. I do not think that actually setting this property for production builds is a good idea, so I recommend against that (ultimately that will be up to Gluon or whoever produces builds).
I'll test it once you change it from an env variable to a gradle property.