Support Gradle's reproducible archives when building fat jars and wars #8391
Comments
A related question: SpringBootPlugin doesn't extend AbstractArchiveTask. Should it? Would doing so make supporting new features like this easier? (I honestly don't know the answer to that question at all — just throwing it out there) |
Thank you for the detailed problem report and the sample.
It's |
Oh.... This is exciting! Can't wait to check this out! |
Unfortunately, the example doesn't create a reproducible archive for me with spring boot 2.0.0.M7. When I build with the gradle recommended options for reproducible builds
The build is still producing jar files with different sha checksums. I've updated the repo I created before, but I've stuck gradle 2.0.0.M7 on a [different branch] (https://github.com/seanjreilly/spring-boot-gradle-plugin-issue/tree/2.0.0.M7) to make it easier to switch back and forth between 1.0 and 2.0. Is there any way this issue can be reopened? |
Thanks for the updated sample. It works fine for me with Gradle 4.0. With 4.1 and later, it's failing because the
I've opened #11468. |
Thanks @wilkinsona. I'm sorry to say that I didn't test with any versions of Gradle other than the current (I probably should have done so before asking to reopen — I'll try to do better on that in the future).
I agree. I don't even see any particular value in having the same timestamps as a non-boot archive, as long as every spring boot archive has the same timestamps between runs.
If the sample I've produced can help with that in any way I'll gladly donate it. I'm happy to transfer ownership, sign an agreement, move to a specific license, etc. I appreciate the thorough attention to such a specific edge case. |
There's really no need to be better. The sample you provided was already very helpful. Thanks for the offer to donate the sample, but I've already taken care of fixing (I hope) and testing this in b545330. |
The commit looks good to me, and the integration tests are the integration tests I would have written. I'm confident that this will fix the issue, and keep it fixed. Thanks so much! |
@wilkinsona This is still an issue in springBoot {
buildInfo()
} Because the plug-in includes the This is in the |
@jzampieron That’s really a separate problem. Please open a new issue and we’ll see what we can do |
An important feature of Gradle 3.4 is its initial support for reproducible archives.
(In short, reproducible builds mean that a given revision of source code should always build the exact same binary, byte-for-byte. See https://reproducible-builds.org/ for more info).
With the right settings as described in gradle documentation, building the same basic java project twice results in two jars with the same SHA-256 hash. However, when I tried the same thing with a project that uses the spring-boot plugin, I couldn't get it to work.
I've created a github repo with a minimal reproducible example of the issue.
Steps to reproduce the issue.
(run all commands from the root project directory of the cloned repo)
./gradlew clean java-plugin:build
cp java-plugin/build/libs/java-plugin-0.0.1-SNAPSHOT.jar /tmp/java-plugin-1.jar
./gradlew clean java-plugin:build
cp java-plugin/build/libs/java-plugin-0.0.1-SNAPSHOT.jar /tmp/java-plugin-2.jar
shasum -a 256 /tmp/java-plugin-*.jar
e1358db781e755047d9a6c504481d078f15bf259df4b81c23c7260b5ecd4e6ef
. If it's not, I'd be interested in hearing about that.)./gradlew clean spring-boot-plugin:build
cp spring-boot-plugin/build/libs/spring-boot-plugin-0.0.1-SNAPSHOT.jar /tmp/spring-boot-plugin-1.jar
./gradlew clean spring-boot-plugin:build
cp spring-boot-plugin/build/libs/spring-boot-plugin-0.0.1-SNAPSHOT.jar /tmp/spring-boot-plugin-2.jar
shasum -a 256 /tmp/spring-boot-plugin-*.jar
I checked out the differences with diffoscope, and the differences I could see were related to file timestamps in the uber jar.
The text was updated successfully, but these errors were encountered: