PREQ-6264: Add Gradle wrapper download retries in config-gradle

[tomverin]

Summary

• Add a Configure Gradle wrapper download resilience step to config-gradle that sets networkTimeout=60000, retries=3, and retryBackOffMs=1000 in gradle/wrapper/gradle-wrapper.properties at CI runtime
• Mitigates flaky Gradle distribution downloads (e.g. services.gradle.org timeouts on sonar-scanner-engine) without requiring per-repo wrapper property changes

Jira: https://sonarsource.atlassian.net/browse/PREQ-6264

Related: Julien Henry reported Gradle download timeout in https://github.com/SonarSource/sonar-scanner-engine/actions/runs/27123611072/job/80050116778 — wrapper had retries=0 and networkTimeout=10000.

Test plan

• CI passes on this PR
• After release on @v1, verify sonar-scanner-engine Gradle build no longer flakes on distribution download

[hashicorp-vault-sonar-prod]

PREQ-6264

[Copilot]

Pull request overview

Adds a CI-time hardening step to the config-gradle composite action to reduce flakiness when downloading the Gradle distribution via the wrapper, without requiring per-repo wrapper changes.

Changes:

• Introduces a new “Configure Gradle wrapper download resilience” step that edits gradle/wrapper/gradle-wrapper.properties at runtime.
• Ensures networkTimeout=60000, retries=3, and retryBackOffMs=1000 are present/updated when a wrapper properties file exists.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gitar-bot]

Code Review ✅ Approved 3 resolved / 3 findings

Adds Gradle wrapper download resilience through increased timeouts and retries, resolving the potential for file corruption by ensuring a trailing newline is present before appending properties.

✅ 3 resolved

✅ Edge Case: Appending wrapper prop without trailing newline corrupts file

📄 config-gradle/action.yml:153-160
In the new update_prop function, when a property key is not already present, it is appended with echo "${key}=${value}" >> "$WRAPPER_PROPS". If gradle-wrapper.properties does not end with a trailing newline (not guaranteed — files edited by some tools or generated without a final newline), the new line is concatenated onto the previous line. For example if the file's last line is distributionUrl=https://...gradle-8.5-bin.zip with no trailing newline, the result becomes distributionUrl=https://...gradle-8.5-bin.zipnetworkTimeout=60000, which corrupts the distributionUrl and breaks the Gradle wrapper entirely — the opposite of the intended resilience improvement.

Guard the append by ensuring the file ends with a newline first, e.g.:

else
  [[ -n "$(tail -c1 "$WRAPPER_PROPS")" ]] && echo >> "$WRAPPER_PROPS"
  echo "${key}=${value}" >> "$WRAPPER_PROPS"
fi

This appends a newline only when the file does not already end with one.

✅ Bug: retries/retryBackOffMs are not recognized gradle-wrapper.properties keys

📄 config-gradle/action.yml:163-165
The new step writes networkTimeout, retries, and retryBackOffMs into gradle/wrapper/gradle-wrapper.properties. Only networkTimeout (Gradle 7.6+) is a wrapper property that Gradle actually reads. The Gradle wrapper's recognized keys are distributionBase, distributionPath, distributionUrl, distributionSha256Sum, zipStoreBase, zipStorePath, networkTimeout, and validateDistributionUrl. retries and retryBackOffMs do not appear to be honored by the wrapper's distribution download logic, so they would be silently ignored.

If that is the case, this PR's primary goal — adding download retries to mitigate flaky services.gradle.org downloads — would not be achieved; only the timeout bump from 10000ms to 60000ms would take effect. Please verify against the Gradle version in use that retries/retryBackOffMs are read by the wrapper. If they are not supported, retries should be implemented differently (e.g. wrapping the ./gradlew invocation with a retry loop, or pre-downloading/caching the distribution with retry), and the unsupported keys should be removed to avoid polluting the wrapper file and the cache key.

✅ Edge Case: Mutating wrapper props before cache-key step silently shifts the cache key

📄 config-gradle/action.yml:142-156 📄 config-gradle/action.yml:178-191
This step rewrites gradle/wrapper/gradle-wrapper.properties, and the later 'Generate Gradle Cache Key' step (line 184) includes that same file in the md5 sum used for GRADLE_CACHE_KEY. Because the file is modified in place at CI runtime before the key is computed, the cache key now reflects the rewritten values rather than the repository's committed wrapper file. This is consistent across runs (so caching still works), but it means the key silently diverges from what a developer would compute locally from the checked-in file, and any future change to the injected values will invalidate all existing Gradle caches. Consider documenting this coupling, or computing the cache key from the original file contents before mutation.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}