Skip to content

BSP-19784: Update Sonar to Java 21 - #86

Merged
lteague merged 2 commits into
v2from
feature/BSP-19784-sonar-java-21
Jul 29, 2026
Merged

BSP-19784: Update Sonar to Java 21#86
lteague merged 2 commits into
v2from
feature/BSP-19784-sonar-java-21

Conversation

@cal-ch

@cal-ch cal-ch commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

@claude

claude Bot commented Jul 14, 2026

Copy link
Copy Markdown

Claude encountered an error —— View job


I'll analyze this and get back to you.

The Sonar steps hardcoded JAVA_HOME to a JAVA_HOME_<n>_X64 runner
variable, overriding whatever java-version the caller passed to
setup-java. SonarQube Cloud no longer supports Java 17, so analysis
failed for every consumer regardless of the version it requested.

Remove the inline overrides and take JAVA_HOME from the setup-java
step output instead. A new resolve step raises java-version to 21
when it is lower or cannot be parsed, emitting a warning, and passes
21 or newer through untouched so pins such as 21.0.2 survive. The
input default moves from 11 to 21 to match the scanner requirement.
@claude

claude Bot commented Jul 29, 2026

Copy link
Copy Markdown

Claude encountered an error —— View job


I'll analyze this and get back to you.

@lteague
lteague merged commit f53e501 into v2 Jul 29, 2026
1 check failed
@lteague
lteague deleted the feature/BSP-19784-sonar-java-21 branch July 29, 2026 16:21
lteague pushed a commit that referenced this pull request Jul 29, 2026
#86 made the whole job run on max(java-version, 21), because the
scanner has a hard 21 floor. That also forced the Build step up, so a
consumer whose build/deploy workflow uses an older JDK now gets Gradle
cache keys that miss those warm remote-cache entries, turning a cached
sonar job into a full rebuild — tests and bytecode enhancement included.

Run the build on java-version verbatim and the scan on
max(java-version, 21), both derived from the one input. At 21 or newer
they resolve to the same value, so the common case stays a single JDK
and a single Gradle daemon. Below the floor only the scan is raised,
which is the safe direction: analysing older bytecode on a newer JDK is
tolerable, and versions.java already has to be <= java-version for the
build to compile.

Install both JDKs with setup-java unconditionally rather than gating the
second one or falling back to a JAVA_HOME_<n>_X64 runner variable. Those
are image-dependent and expand to empty when absent, which is how the
scan came to run on 17 regardless of this input.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants