Skip to content
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

Update Gradle to 7.6 #668

Merged
merged 3 commits into from
Jul 12, 2023
Merged

Update Gradle to 7.6 #668

merged 3 commits into from
Jul 12, 2023

Conversation

Vampire
Copy link
Contributor

@Vampire Vampire commented Feb 8, 2023

Subject says it all :-)

@LouisCAD
Copy link
Member

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.

@LouisCAD LouisCAD merged commit 7b5c147 into Splitties:main Jul 12, 2023
1 check failed
@Vampire Vampire deleted the gradle-7-6 branch July 20, 2023 14:37
@Vampire
Copy link
Contributor Author

Vampire commented Jul 20, 2023

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
Copy link
Member

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 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants