Delete distribution zip file after installing from the wrapper

[altrisi]

Fixes #19480, fixes #3605.

Context

Each gradle distribution zip uses around (recently over) 100MB (110MB for 7.3). If you update the gradle installation in projects regularly via the wrapper, this can fill up your drive with lots of unnecessary data, given the extracted files are next to it and the zip isn't ever used again for anything.

This PR also removes the line in the tests that checks for the zip to be present, given it's not actually needed to reuse the distribution (only the ok file is). You can see an image of gradle launching without the zip here.

Contributor Checklist

• Review Contribution Guidelines
• Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
• Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
• Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
• Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
• Provide unit tests (under <subproject>/src/test) to verify logic
• Update User Guide, DSL Reference, and Javadoc for public-facing changes
• Ensure that tests pass sanity check: ./gradlew sanityCheck
• Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Tests also ran in an action runner in https://github.com/altrisi/gradle/actions/runs/1658407331.

Gradle Core Team Checklist

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation
• Recognize contributor in release notes

Signed-off-by: altrisi altrisi.trillosierra@gmail.com

[altrisi]

Sorry, I'm unable to see/understand what failed there.

[donat]

@altrisi Sorry for the confusion.

The failure is here. You should be able to log in with a guest account. For future reference, let me know if it doesn't work.

The stacktrace is below:

======= Failed test run #1 ==========
  Condition not satisfied:
  
  Hashing.sha256().hashFile(file("first/gradle/wrapper/gradle-wrapper.jar")) == HashCode.fromString("33ad4583fd7ee156f533778736fa1b4940bd83b433934d1cc4e9f608e99a6a89")
  |       |        |        |                                                |  |        |
  |       SHA-256  |        |                                                |  |        33ad4583fd7ee156f533778736fa1b4940bd83b433934d1cc4e9f608e99a6a89
  |                |        |                                                |  class org.gradle.internal.hash.HashCode
  |                |        |                                                false
  |                |        /home/tcagent1/agent/work/a8634df19932fe57/subprojects/wrapper/build/tmp/test files/WrapperGene.Test/g6rai/first/gradle/wrapper/gradle-wrapper.jar
  |                662ff42afe8cdea709ca1364534f734f0e4c3e230eef98325cd7c9d7b0227f16
  class org.gradle.internal.hash.Hashing
  Condition not satisfied:
  Hashing.sha256().hashFile(file("first/gradle/wrapper/gradle-wrapper.jar")) == HashCode.fromString("33ad4583fd7ee156f533778736fa1b4940bd83b433934d1cc4e9f608e99a6a89")
  |       |        |        |                                                |  |        |
  |       SHA-256  |        |                                                |  |        33ad4583fd7ee156f533778736fa1b4940bd83b433934d1cc4e9f608e99a6a89
  |                |        |                                                |  class org.gradle.internal.hash.HashCode
  |                |        |                                                false
  |                |        /home/tcagent1/agent/work/a8634df19932fe57/subprojects/wrapper/build/tmp/test files/WrapperGene.Test/g6rai/first/gradle/wrapper/gradle-wrapper.jar
  |                662ff42afe8cdea709ca1364534f734f0e4c3e230eef98325cd7c9d7b0227f16
  class org.gradle.internal.hash.Hashing
    at org.gradle.integtests.WrapperGenerationIntegrationTest.generated wrapper files are reproducible(WrapperGenerationIntegrationTest.groovy:74)
  ------- Stdout: -------
  > Task :wrapper
  BUILD SUCCESSFUL in 67ms
  1 actionable task: 1 executed
  > Task :wrapper
  BUILD SUCCESSFUL in 56ms
  1 actionable task: 1 executed
  [com.gradle.enterprise.testdistribution] Test was part of session 2 and ran on a local executor named 'localhost-executor-4' on host 'localhost'.

I've quickly fixed the problem on your branch, see the commit message for the explanation.

Feel free to squash commits and remove my face from your feature branch. :)

[altrisi]

Sorry for the delay, been busy with exams, will take a look later to see why the test failed (though I don't see how could that have changed because of the changes here).

Will also refactor it to match the new project structure and run tests again.

[donat]

@ljacomet I've built a local distribution with the changes and verified the integrity of the wrapper download. If I execute two builds with the same wrapper, the first build triggers the distribution download while the second one waits idle. Once the download finishes, both build start in parallel.

[donat]

Requesting a review from the @gradle/bt-core team as I'm not confident that this PR can be merged.

[altrisi]

Oh yeah, I'd have to check whether this is compatible after the recent wrapper changes, which I haven't yet.

However, I don't really have time right now so feel free to check by yourselves, it's a really trivial change.

[big-guy]

@donat This seems like a good idea to me

[big-guy]

@bigdaz does this impact the GH action at all?

[bigdaz]

@bigdaz does this impact the GH action at all?

Yes it will require changes to the GH action. Currently, the action will save/restore the downloaded wrapper zip and not the extracted install: https://github.com/gradle/gradle-build-action/blob/main/src/cache-extract-entries.ts#L313-L314. (Note we do something similar for java toolchains).

That said, I'm OK with changing this in gradle-build-action to accommodate the change in Gradle.

[bigdaz]

@big-guy I've now adapted the gradle-build-action to save/restore the exploded dist directory rather than the downloaded zip file, and will release a new version soon. So as long as users have the latest action version, they will continue to see full caching even after this PR is merged.

[altrisi]

Is this accepted then? If so, what would be missing for a merge?

To me it seems only remaking the wrapper hash, but want to be sure to not have to redo it more times. Would also need to know if there's some specific way to generate it or if I should just get the hash of a built jar, given there's no instructions on how to set that field (or that it should be changed even) in the contributing files.

I can probably finish it next week then (or feel free to just change the hash and merge if it's all that's needed).

[altrisi]

I have updated the wrapper's hash with the result of certutil on my computer.

Is there anything else missing? Other than telling bot-gradle to test this, that I don't think I can do.

[donat]

Is there anything else missing?

We'll take it from here.

[donat]

@bot-gradle test and merge

[bot-gradle]

No milestone for this PR. Please set a milestone and retry.

[donat]

@bot-gradle test and merge

[bot-gradle]

OK, I've already triggered a build for you.

[altrisi]

Just curious, was this really meant to go in as far as 7.6 RCs? I feel like it's been ages since this change was merged (way more since submitted) and it still isn't in a release, being such a trivial change...
Edit: And also near to 5 years since original issue creation...