Nevermind - delete me

Bugs
1

Sorry I fired this one off too soon – see comments at the bottom.

I tried updating two projects to Gradle 2.7 and setting the distributionSha256Sum property with:

shasum -a 256 ~/.gradle/wrapper/dists/gradle-2.7-bin/4s0fcuuppw3tjb1sxpzh16mne/gradle-2.7-bin.zip

The result I get is:

cde43b90945b5304c43ee36e58aab4cc6fb3a3d5f9bd9449bb1709a68371cb06

Just to test that I have things configured correctly, I modified the hash to end in a ‘7’ rather than a ‘6’:

cde43b90945b5304c43ee36e58aab4cc6fb3a3d5f9bd9449bb1709a68371cb07

When I run

./gradlew build

No error is reported.

OK, this is the Bug Fix: https://issues.gradle.org/browse/GRADLE-3337

So, I’ve got to do an

rm -rf ~/.gradle/wrapper/dists/gradle-2.7-bin/

to force it to re-download then the check will fail.

It would be nice if there as an option to force validation.

Regards,

Sean

2

Is that just for confirming that your checksum is correct before committing? You could do the same thing by just running a single build with a different gradle user home (e.g., gradlew -g /path/to/somewhere help). Is there any other reason you’d want to check the checksum otherwise?

3

I want to confirm that Gradle is in fact checking the checksum and that I have everything configured correctly so that an issue will be detected if it happens.

I’m working on software that will handle digital currency, so I’m working hard at being paranoid.

4

OK, so I think the suggestion of using a different gradle user home to check that the checksum is configured correctly (and the version of gradle being downloaded matches) is better than a dedicated flag to recheck. That mimics what another user (or you on another machine) would be doing. The only time you’re going to fail the checksum check is when the Gradle distribution is downloaded/unzipped the first time.

5

Fair enough. Though it will also be slower and potentially use a bunch of disk space. On other hand it tests more than just the one issue.