Repository navigation
build: download the Gradle wrapper from Gradle's GitHub releases - #195
Conversation
The wrapper fetched gradle-9.8.2-bin.zip from services.gradle.org, with a 10 s timeout and no retries. On 2026-11-08 that host returned 504 for minutes at a time, and every CI job that builds this repo failed before compiling anything, protowire's cross-port security gate included (trendvidia/protowire#592). Gradle publishes the same files as releases of gradle/gradle-distributions on GitHub, which is where CI runs. distributionSha256Sum pins the file to the checksum Gradle publishes, so the wrapper refuses anything else.
|
Also: |
|
CI result: the GitHub download works, but it is not reliable on its own. Every job downloaded from |
With the download moved to GitHub's releases, 3 of 6 CI jobs still
failed: each stalled reading from release-assets.githubusercontent.com
and gave up at networkTimeout=10000 on its only attempt
("Attempt 1/1 failed ... Read timed out"). A stalled read is what a
longer timeout and a retry are for. Checked against an address that
never answers: the wrapper then reports "Attempt 1/4" to "Attempt 4/4".
The conformance job runs the cross-port gates, which build this repo through ./gradlew, but set up no Gradle cache. So the wrapper downloaded Gradle on every run, and the gate scripts print a build's output only when it fails. That is where 'Downloading ... failed: timeout (10000ms)' came from. The build job already caches it through setup-gradle, and on main it restores gradle-wrapper-zips-v2-* and downloads nothing.
|
CI is green at |
* ci: cache the Gradle distribution in the cross-port gates The security, text, write and envelope gates build protowire-java through its wrapper but set up Java without any Gradle cache, so each run downloaded Gradle from services.gradle.org. On 2026-11-08 that host returned 504 for minutes at a time, and the security gate failed three times before it reached the corpus (run 42440559767, attempts 2-4). setup-gradle caches the distribution, as protowire-java's own CI already does. * ci: cache the Gradle distribution in CodeQL's java-kotlin job The job builds the JetBrains plugin through its wrapper without a Gradle cache, so it downloaded Gradle on every run. editors-jetbrains.yml already caches it with setup-gradle. The plugin turns on the build cache, so the compile CodeQL traces now passes --no-build-cache: classes restored from the cache are never compiled, and CodeQL would find no code to analyse (protowire-java's codeql.yml hit the same thing). * editors/jetbrains: download Gradle from GitHub, wait 60 s and retry 3 times Same change as trendvidia/protowire-java#195 and trendvidia/protowire-kotlin#28. The wrapper fetched Gradle from services.gradle.org with a 10 s timeout and no retries. It now fetches Gradle's own copy from the gradle/gradle-distributions releases on GitHub, pinned by distributionSha256Sum to the checksum Gradle publishes, and retries a stalled download. --------- Co-authored-by: TrendVidia <coder@trendvidia.com>
CI could not build this repo whenever services.gradle.org was down. The wrapper downloads Gradle from there with a 10-second timeout and no retries. On 2026-11-08 that host returned 504 for minutes at a time, so every job that builds protowire-java failed before compiling anything. That includes protowire's cross-port security gate, which then blocked an unrelated PR (trendvidia/protowire#591; see trendvidia/protowire#592).
This PR points the wrapper at Gradle's own copy of the same file on GitHub (the
gradle/gradle-distributionsreleases), which is where CI runs. It also addsdistributionSha256Sum, so the wrapper refuses any file but Gradle's.Advances trendvidia/protowire#592 by a different route. That issue asked for a cache; this removes the download from services.gradle.org instead.
Evidence
21bd5da2…e389607. That equals Gradle's publishedgradle-9.8.2-bin.zip.sha256.GRADLE_USER_HOME,./gradlew --versionprintedDownloading https://github.com/gradle/gradle-distributions/releases/download/v9.8.2/gradle-9.8.2-bin.zip, thenGradle 9.8.2../gradlew --quiet :check-decode:installDistexits 0 and producescheck-decode/build/install/check-decode/bin/check-decode.Expected checksum: '00bd5da2…'/Actual checksum: '21bd5da2…'.Watch on the next Gradle upgrade
Dependabot updates this file (#132 changed only the version inside the URL). How it treats a GitHub URL I can't test until the next Gradle release. There are two ways it could go wrong:
So review the next wrapper bump for the host and the checksum. Not in the changelog, since nothing a user of the library sees changes.