Update Gradle to 9.7.0

[serhiy-bzhezytskyy]

Description

Updates Gradle from 9.4.1 to 9.7.0.

The wrapper bump alone is two lines, but this repository sets systemProp.org.gradle.warning.mode=fail, so every deprecated Gradle API in the build logic is a hard error before the build will run. Measured on main: zero Gradle deprecations on 9.4.1, 22 on 9.6/9.7. The rest of the change resolves them; all 22 also become errors in Gradle 10.

Changes by class:

• Project.exec / javaexec removed — inject ExecOperations (distribution/docker, distribution/docker/docker-build-context, plugins/repository-hdfs, qa/os/windows-2012r2, qa/os/windows-2016).
• Task convention/extension access replaced with the current API (PluginBuildPlugin, StandaloneRestTestPlugin, RestTestUtil, JarHellPrecommitPlugin, LoggerUsagePrecommitPlugin, ThirdPartyAuditPrecommitPlugin).
• RepositoriesSetupPlugin — getArtifactUrls() is gone in Gradle 9.6+, so the per-artifact-URL assertRepositoryURIIsSecure loop cannot be kept. The reason is now a comment in the file. Repository-level URL checks are unaffected; only the extra per-artifact-URL pass is lost.
• Remaining API migrations in build.gradle, buildSrc/build.gradle, distribution/build.gradle.

Wrapper artifacts, all three aligned to 9.7.0 and independently verifiable against https://gradle.org/release-checksums/:

artifact	value
gradle/wrapper/gradle-wrapper.properties	gradle-9.7.0-all.zip, distributionSha256Sum=a9ecb5ac5c2ca40691e6527724d11d0b43b8c0a52825b77c09899f2a72d2d2bf
gradle/wrapper/gradle-wrapper.jar	sha256 7a9ce74cff467ca1bf60a4fcd9f05185acceda4d0f382434d393e17864262c5d
buildSrc/src/main/resources/minimumGradleVersion	9.7.0

⚠️ On the committed wrapper JAR. On main it is the official 9.2.0 wrapper JAR while main pins the 9.4.1 distribution — the two have been out of step for several releases. This PR sets it to the official 9.7.0 JAR so it matches the pinned distribution and its checksum can be verified against the published value above. Flagging this explicitly because Code-Diff-Analyzer correctly raises the replacement of a build-tool binary as a supply-chain concern; the checksums above are exactly what it asks a maintainer to confirm.

Related Issues

Resolves #22718
Supersedes #22638 and #22639, which proposed the same work targeting 9.6.1. Retargeted because 9.7.0 shipped on 2026-08-06 and needs no additional changes over 9.6.1 — verified locally: identical file set, and both the configuration phase and a full compile pass with no Gradle deprecations. Both are being closed in favour of this PR, which is also rebuilt on current main (the 9.6.1 branch was 30 commits behind).

Check List

• Functionality includes testing. (Build-only change; the build is the surface. Verified locally as listed below, and gradle-check exercises the full suite under the new Gradle.)
• API changes companion pull request created, if applicable. (n/a)
• Public documentation issue/PR created, if applicable. (n/a — build only)

Verified locally with Gradle 9.7.0 on JDK 21:

• ./gradlew --version reports Gradle 9.7.0
• ./gradlew precommit --dry-run — configuration phase clean, which is where warning.mode=fail bites
• ./gradlew :server:compileJava :buildSrc:build -x :buildSrc:test
• no Deprecated Gradle features were used in this build notice in either run

I did not run the full test suite locally; leaving that to gradle-check.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

PR Code Analyzer ❗

AI-powered 'Code-Diff-Analyzer' found issues on commit d1e07ad.

⛔ Hard block: Issues at Medium severity or above will block this PR from merging.

Path	Line	Severity	Description
gradle/wrapper/gradle-wrapper.jar	1	high	Binary Gradle wrapper JAR replaced. This file executes on every Gradle invocation and is a well-known supply chain attack vector. The new binary must be verified against official Gradle release checksums.
gradle/wrapper/gradle-wrapper.properties	4	high	Gradle distribution URL changed from 9.4.1 to 9.7.0 and SHA256 hash updated. Mandatory flag: changing the distribution URL and expected hash for a build tool constitutes a supply chain dependency change that must be independently verified against official Gradle release signatures.
buildSrc/src/main/resources/minimumGradleVersion	1	high	Minimum required Gradle version bumped from 9.4.1 to 9.7.0. Mandatory flag: build toolchain version constraint change that enforces use of the new Gradle distribution referenced above.
buildSrc/src/main/java/org/opensearch/gradle/RepositoriesSetupPlugin.java	73	medium	Removes the loop that called assertRepositoryURIIsSecure on each entry in maven.getArtifactUrls(). While the comment attributes this to Gradle 9.6 deprecation, it eliminates a security control that previously blocked insecure (non-HTTPS) artifact source URLs, reducing defence-in-depth against repository hijacking.

The table above displays the top 10 most important findings.

Total: 4 | Critical: 0 | High: 3 | Medium: 1 | Low: 0

---

Pull Requests Author(s): Please update your Pull Request according to the report above.

Repository Maintainer(s): You can bypass diff analyzer by adding label skip-diff-analyzer after reviewing the changes carefully, then re-run failed actions. To re-enable the analyzer, remove the label, then re-run all actions.

---

⚠️ Note: The Code-Diff-Analyzer helps protect against potentially harmful code patterns. Please ensure you have thoroughly reviewed the changes beforehand.

Thanks.

[serhiy-bzhezytskyy]

@reta @andrross — tagging you as the two who have carried the Gradle upgrades here (#21153, #20833), because this one is bigger than the usual bump and there is one thing only a maintainer can unblock.

Why this is 20 files and not 2. gradle.properties sets systemProp.org.gradle.warning.mode=fail, so every deprecated Gradle API in the build logic is a hard error before the build runs. Measured on main: 0 deprecations on 9.4.1, 22 on 9.6/9.7. #21153 was two files precisely because 9.4.1 introduced none. All 22 also become errors in Gradle 10, so the work is due regardless of which version we land.

What needs a maintainer. Code-Diff-Analyzer hard-blocks on two high-severity findings, and it is right to: any Gradle bump here replaces the committed gradle/wrapper/gradle-wrapper.jar and changes the distribution URL. It asks for the artifact to be verified against the official release checksums, which is exactly what a maintainer can do and I cannot. Both values are the published ones from https://gradle.org/release-checksums/:

artifact	sha256
gradle-9.7.0-all.zip	a9ecb5ac5c2ca40691e6527724d11d0b43b8c0a52825b77c09899f2a72d2d2bf
gradle-wrapper.jar	7a9ce74cff467ca1bf60a4fcd9f05185acceda4d0f382434d393e17864262c5d

If those check out, this needs the skip-diff-analyzer label to proceed.

One thing worth fixing while we are here. The committed wrapper JAR on main is the official 9.2.0 JAR, while main pins the 9.4.1 distribution. It has been drifting since #20833, and I think the cause is a documented footgun rather than anyone's oversight: the wrapper task has to be run twice, as Gradle's own release notes put it —

./gradlew :wrapper --gradle-version=9.7.0 && ./gradlew :wrapper

The first run rewrites gradle-wrapper.properties; the second, now executing under the new distribution, rewrites the JAR and the scripts. Run once, and the JAR stays at whatever version was previously in use. My own earlier attempt (#22639) hit this too and shipped the 9.4.1 JAR against a 9.6.1 URL — Code-Diff-Analyzer flagged it and I initially mis-read the finding as being about the binary rather than about my change. This PR sets all three artifacts to 9.7.0 consistently: properties, JAR, and buildSrc/src/main/resources/minimumGradleVersion.

On the red checks. assemble (21, ubuntu-24.04-arm) failed at step 3, "Install protoc (Linux)", with curl: (22) ... error: 503 — before Gradle started; the other seven were cancelled by fail-fast. Nothing in this diff touches protoc or the workflows, so a re-run should clear it. gradle-check was skipped and has not run yet.

Verified locally with Gradle 9.7.0 on JDK 21: precommit --dry-run (the configuration phase, where warning.mode=fail bites), :server:compileJava, :buildSrc:build, and no Deprecated Gradle features were used in this build notice in either run. I have not run the full suite locally.

[reta]

Please revert that to 9.4.1 - otherwise it will break every single plugin build (until they move to 9.7.0 as well)

[serhiy-bzhezytskyy]

Reverted in 18b7d3e, thanks.

[reta]

Ah ... this is unfortunate, may be we could keep libs (at catalog reference) but rename libs configuration? (fe libsOther)

[serhiy-bzhezytskyy]

I tried exactly that first, and it doesn't help — the deprecation isn't a name clash. With the configuration renamed and bcFips libs.bundles.bouncycastle restored, the build still fails:

Property 'libs' was not declared in project ':distribution:archives' and was resolved from project ':distribution'.
	at distribution/build.gradle:345

So it is the catalog accessor itself being resolved by implicit lookup in the parent: the configure(subprojects.findAll { ... }) block runs against :distribution:archives and :distribution:packages, where libs is not declared.

Kept the configuration name and captured the bundle where the accessor is in scope instead (18b7d3e):

def bouncycastleBundle = libs.bundles.bouncycastle

configure(subprojects.findAll { ['archives', 'packages'].contains(it.name) }) {
  ...
    bcFips bouncycastleBundle

That also drops the VersionCatalogsExtension boilerplate I had, so the diff is smaller than before.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit 18b7d3e)

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

📝 TODO sections buildSrc/src/main/java/org/opensearch/gradle/RepositoriesSetupPlugin.java [65]: remove this with gradle 7.0, which no longer allows insecure urls

🔀 No multiple PR themes

⚡ No major issues detected

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Remove stray duplicate version line The minimumGradleVersion file appears to contain two lines after the change (9.7.0 and 9.4.1), which is likely a merge/edit artifact. This file should contain a single version line, otherwise any code that reads it (e.g., readAllLines/first-line parsing) may misbehave or the second line will be treated as extra content. buildSrc/src/main/resources/minimumGradleVersion [1-2] --9.4.1 -+9.7.0 - 9.4.1 +9.7.0 Suggestion importance[1-10]: 9 __ Why: The minimumGradleVersion file appears to have two version lines after the change, which is almost certainly a mistake and could cause version parsing issues in the build system.	High

[github-actions]

❌ Gradle check result for d1e07ad: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Persistent review updated to latest commit 18b7d3e

[serhiy-bzhezytskyy]

gradle-check 83408 had 8 failures / 28,929 passed. Five were mine and are fixed in 18b7d3e; three are pre-existing.

Mine — ThirdPartyAuditTaskIT, 5 tests. ThirdPartyAuditTaskIT:135 is assertNoDeprecationWarning(result), so the nested build must emit no deprecations. Under 9.7.0 it emits one, from the fixture itself:

The Project.getProperties method has been deprecated.
	at buildSrc/src/testKit/thirdPartyAudit/build.gradle:50

project.properties.compileOnlyGroup → findProperty('compileOnlyGroup'). findProperty is used rather than providers.gradleProperty(...).get() because get() throws when the property is absent, and testWithEmptyRules does not pass those -P arguments. All six tests in the class pass locally now.

Pre-existing — InternalDistributionBwcSetupPluginFuncTest, 3 tests. All three fail in the third-level build, checkout-8.0/gradlew:

Fetching distribution.
 [8.0.1] Downloading https://services.gradle.org/distributions/gradle-9.7.0-bin.zip
 [8.0.1] Attempt 1/1 failed. Reason: Unexpected end of file from server

The class has an open flaky report, #19808, which records it failing during post-merge and timer-triggered runs on main, and the Jenkins report for these three says "Failing for the past 7 builds (Since #83402)" — this build is 83408.

[github-actions]

❌ Gradle check result for 18b7d3e: null

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[serhiy-bzhezytskyy]

The gradle-check on 18b7d3ed never reached Jenkins, so the fixes in that commit have not been tested yet. The job polled for the full two hours and gave up:

Use queue information to find build number in Jenkins if available
jq: parse error: Invalid numeric literal at line 1, column 7
WORKFLOW_URL
Job not started yet. Waiting for 60 seconds before next attempt.
time passed: 7260
Please check jenkins url for logs:
Result: null

WORKFLOW_URL stayed empty, which is why the result comment above links to [null](). The jq parse error at column 1:7 is the poller receiving HTML rather than JSON.

It was not specific to this PR — another run in the same window ended identically with Result: null after 7260 s. Runs since then are reaching Jenkins normally (real results after ~1950 s), so a re-run should work now.

Could someone re-trigger gradle-check when convenient?

[github-actions]

❌ Gradle check result for 18b7d3e: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?