Splitties / refreshVersions

Life is too short to google for dependencies and versions
https://splitties.github.io/refreshVersions/
MIT License
1.63k stars 107 forks source link

Update Gradle to 7.6 #668

Closed Vampire closed 11 months ago

Vampire commented 1 year ago

Subject says it all :-)

LouisCAD commented 11 months ago

Thank you!

FYI, there's a new syntax for getting the current project as a dependency: project().

Also, for Gradle updates, I prefer that we do it ourselves to be sure that malicious wrapper jar and scripts are not introduced. Here, it looks like the wrapper is different when generated from Gradle 8.1.1 even though I specified the version 7.6. I tried to look into the diff but didn't see anything alarming. If you know why we had different outcomes, I would be interested to learn more.

Vampire commented 11 months ago

FYI, there's a new syntax for getting the current project as a dependency: project().

Yep, I know. At least in the meantime. :-) Might not have known back then or forgotten it.

Also, for Gradle updates, I prefer that we do it ourselves to be sure that malicious wrapper jar and scripts are not introduced.

Sure, I seldomly update other projects Gradle versions, but I wanted to test with using the project as included build. But for that, it needs to be compatible with the build including it. And as the project I tested it with was on 7.6 with the changed API for the test suites, I fixed it on-the-fly and thought I submit it too. :-)

Against malicious wrapper introduction, you should maybe add a GitHub action run that uses the gradle/wrapper-validation-action which is for exactly that use-case, ensuring the wrapper jar has one of the officially released checksums. Malicious build logic you hopefully would find by reviewing the changes, but hopefully in nothing I send. :-)

Here, it looks like the wrapper is different when generated from Gradle 8.1.1 even though I specified the version 7.6. I tried to look into the diff but didn't see anything alarming. If you know why we had different outcomes, I would be interested to learn more.

The 4 wrapper file are generated from the Gradle version you use to generate the wrapper files. So as you used 8.1.1 to regenerate the wrapper files to make sure I'm not evil, you generated that state as of 8.1.1. The version you specify to the wrapper task is only used in the content of gradle/wrapper/gradle-wrapper.properties that defines which version of Gradle is used at runtime. You can also for example calculate the sha256sum of the wrapper jar and search for it on https://gradle.org/release-checksums manually to see that my submitted wrapper jar was from 7.6 while yours is coming from 8.1 or 8.1.1.

Due to that you should practically always run the wrapper task twice (when using the wrapper of the project), first to update the Gradle version in the wrapper file and then to update the actual wrapper files with the state of the new version. Otherwise you are always behind with the actual wrapper files, which usually is not problematic, but of course might miss new improvements or changes in the actual wrapper.

LouisCAD commented 11 months ago

The wrapper GitHub action checks only the jar file, not the shell script, which is not really human readable given its length and the cryptic shell/bash syntax, that's why I haven't been eager to add this one that I knew about.

Thanks for all the info, TIL 😃