New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version 2.13.4 has incorrect Java version discovery. #13541
Comments
|
I fixed this by locking to 2.13.3 but that's not a long term solution. |
|
Hi @brendandburns! Thank you for raising this. We have recently made some changes to CodeQL's ability to discover which versions of Java are installed in the build environment. As you can see in the logs, both versions of CodeQL infer that the project wants to be built with Java 8 (more on that in a moment). The difference is that the old version of CodeQL couldn't find Java 8 installed, and therefore just stuck to the default. The new version of CodeQL can find Java 8 and therefore acts on its conclusion that Java 8 is best for the project. For Maven-based projects, CodeQL looks at the So a simple fix here might be to just change that value in the root-level |
|
Unfortunately, that doesn't work. We mostly build for java 8, but we have one sub-module pom that conditionally builds exclusively for Java 17, because it uses Spring 6 which only supports Java 17: https://github.com/kubernetes-client/java/blob/master/spring-aot/pom.xml#L71 So in this case, infering the language from the base pom.xml doesn't work correctly for this project. Additionally, I think this should be considered a breaking change, since we have something that worked in 2.13.3 and no longer works in 2.13.4 |
|
Thanks for the update that switching to Java 17 for the entire repository is not an option for you. I would recommend that you change the CodeQL workflow to use a manual build, rather than rely on CodeQL's automatic build functionality. In essence, all the automatic build process currently does for you here is:
You can invoke Maven yourself in the CodeQL workflow in place of the automatic build step: - name: Setup Java 17
uses: actions/setup-java@v3
with:
distribution: 'temurin'
java-version: '17.0.x'
# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
uses: github/codeql-action/init@v2
with:
languages: ${{ matrix.language }}
# This is what the CodeQL automatic build currently invokes
- name: Build project
run: ./mvnw clean package -f "pom.xml" -B -V -e -Dfindbugs.skip -Dcheckstyle.skip -Dpmd.skip=true -Dspotbugs.skip -Denforcer.skip -Dmaven.javadoc.skip -DskipTests -Dmaven.test.skip.exec -Dlicense.skip=true -Drat.skip=true -Dspotless.check.skip=true
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v2This will skip the Java version inference and generally give you more control over the build. If you wanted to, you could e.g. build using an older version of Java and exclude the Another approach that I explored would be to teach Maven to actually use the configured Java versions for each project. You can do this by having a workflow which installs both Java 8 and 17: - name: Setup Java 8
uses: actions/setup-java@v3
with:
distribution: 'temurin'
java-version: 8
- name: Setup Java 17
uses: actions/setup-java@v3
with:
distribution: 'temurin'
java-version: 17
# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
uses: github/codeql-action/init@v2
with:
languages: ${{ matrix.language }}
- name: Autobuild
uses: github/codeql-action/autobuild@v2This results in a <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-toolchains-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<toolchains>
<jdk>
<version>8</version>
</jdk>
<jdk>
<version>17</version>
</jdk>
</toolchains>
</configuration>
<executions>
<execution>
<goals>
<goal>toolchain</goal>
</goals>
</execution>
</executions>
</plugin>During the build, Maven will then automatically use the respective Java versions based on what is configured in the submodules' |


I'm using the
setup-javaaction in my config to set the Java version to 17.Previous to the 2.13.4 release, this was detected correctly, but starting with the 2.13.4 releases, it is selecting the built-in Java 8 version that is in the github action image.
Output from 2.13.3:
Output from 2.3.14:
The text was updated successfully, but these errors were encountered: