When using Gradle with GitHub Actions, do you:
1....
# community-supporte
Eli Graber
04/14/2024, 10:57 PMWhen using Gradle with GitHub Actions, do you:
1. Validate the wrapper for each job (1️⃣ )
2. Validate the wrapper only if a wrapper related file changed (2️⃣ )
3. Don't validate the wrapper at all (3️⃣ )
3️⃣ 1
1️⃣ 9
Eli Graber
04/14/2024, 11:02 PMI'm currently doing 1️⃣ , but thinking about switching to 2️⃣ .
The only reason I'm thinking of not switching is because technically a malicious PR could be introduced that changes the wrapper to do something bad (e.g. steal secrets).
My workflow to validate the wrapper would catch that, so it wouldn't get merged in, but the regular workflow would still run with the malicious wrapper.
I can make the regular workflow wait for the validation to finish, but that gets more complicated, and I'd rather just stick with 1️⃣ at that point.
t
Thomas Broyer
04/14/2024, 11:08 PM1️⃣ particularly now that it's just a parameter away with the just released v3.3 or gradle/actions/setup-gradle: https://github.com/gradle/actions/releases/tag/v3.3.0 / https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#gradle-wrapper-validation
Thomas Broyer
04/14/2024, 11:10 PM(I must say I have several projects that just do 3️⃣ too, I need to migrate them to 1️⃣)
c
Chris Lee
04/14/2024, 11:21 PM1️⃣ best not to build anything if the wrapper is invalid, including PR builds.
v
Vladimir Sitnikov
04/15/2024, 5:36 AMThere’s a possibility PR introduces homoglyph gradle-wrapper.jar (e.g. with a Cyrillic e), then 2️⃣ won’t trigger, and you could commit a PR that adds a fake jar :(
p
Philip W
04/15/2024, 7:00 AMI did 2 in the past due the network failures failing the builds, but the checksums are now hardcoded so I will always check the wrapper now before executing it.
e
Eli Graber
04/15/2024, 1:57 PMLooks like I'll be sticking with 1️⃣ 😅