SONARIAC-2775 Fix Docker build on Java 21

[mstachniuk]

In Java 21 there is a change in JDK around starting new processes, the PATH environment variable is not taken into account. This PR fix it.

[mstachniuk]

Example usage: https://github.com/SonarSource/sonar-iac-enterprise/pull/912

[sonar-review-alpha]

Summary

This PR works around a Java 21 change where process creation no longer respects the PATH environment variable. The fix adds a findExecutable() utility that manually resolves executables from PATH to their absolute paths, then uses these resolved paths in Gradle tasks that invoke docker and golangci-lint. This ensures the build works correctly in CI environments running Java 21.

What reviewers should know

Start here: Look at the new findExecutable() function in BuildUtils.kt — it's the core of the fix. It searches PATH directories with platform-specific executable extensions (Windows: .exe, .cmd, .bat; others: none) and returns the absolute path if found, falling back to the bare name if not.

Then review: How it's applied in the two gradle scripts — one for running golangci-lint in the builder, one for docker commands in the environment script. Both follow the same pattern: resolve the executable once, then use the resolved path in commandLine().

Key points for reviewers:

• The fallback to bare executable name means this gracefully degrades if PATH resolution fails
• Only affects executables invoked in CI/Docker contexts (guarded by isCi() checks where applicable)
• Cross-platform compatible (handles Windows extension conventions)
• No runtime behavior change for downstream tasks — just ensures they can find their dependencies

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonar-review-alpha]

Summary

Adds explicit PATH resolution for executables to work around a Java 21 issue where process creation doesn't properly inherit the PATH environment variable. The new findExecutable() utility searches PATH and returns the full path to executables like docker and golangci-lint before they're passed to Gradle Exec tasks, with a fallback to the bare name if not found. This is applied in the two Docker/Go build gradle scripts where external tools are invoked.

What reviewers should know

Start by reviewing the new findExecutable() function in BuildUtils.kt — it contains the logic and explains the Java 21 workaround. Then check the two gradle scripts to see where it's applied: both scripts now resolve docker and the builder script resolves golangci-lint. The changes are minimal and localized; there's no change to how tasks are executed, just where the executable paths come from. The fallback to the bare name means this is backward-compatible if PATH lookup fails.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonar-review-alpha]

Summary

Java 21 changed process creation to not automatically resolve executables from the PATH environment variable. This PR adds a findExecutable() utility function that explicitly searches PATH and returns absolute paths for docker, golangci-lint, and git. This ensures these tools are found correctly when running in Docker builds and CI environments under Java 21+.

What reviewers should know

Start with the new findExecutable() function in BuildUtils.kt (lines 34–54) to understand the fix: it walks the PATH directories and handles Windows extensions, falling back to the bare name if not found. Then review how it's integrated into the two gradle scripts: the docker environment setup calls findExecutable() at the top level to cache the docker path, while the go-binary-builder does the same for golangci-lint. The git call in commitHashProvider() uses it directly. Check that the Path separator and extension handling are correct for the build environment.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[jonas-wielage-sonarsource]

LGTM

[sonarqube-next]

Quality Gate passed for 'cloud-native-gradle-modules'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

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

See analysis details on SonarQube

[sonar-review-alpha]

Conclusion: Clean, targeted fix. The findExecutable() implementation is correct — proper PATH splitting, isFile && canExecute() check, Windows extension handling, and safe fallback. Executable paths are resolved at configuration time and captured in vals before task registration, which is the right pattern. No issues found.

🗣️ Give feedback