Automatic version detection fails when there are warnings

[jerboaa]

Currently, when one builds graal master with a JDK 23 build (e.g. 23+28 ea), mx graalvm-version looks like this:

$ mx --primary-suite-path substratevm graalvm-version
WARNING: Could not parse jvmci version from JVMCIVersionCheck output:
No minimum JVMCI version specified for JDK version 23.

24.2.0-dev

This results in the following version output of a Mandrel build in CI:

./mandrel-build/bin/native-image --version
native-image 23-beta 2024-09-17
OpenJDK Runtime Environment Mandrel-WARNING: Could not parse jvmci version from JVMCIVersionCheck output:-Final (build 23-beta+28-202406240955)
OpenJDK 64-Bit Server VM Mandrel-WARNING: Could not parse jvmci version from JVMCIVersionCheck output:-Final (build 23-beta+28-202406240955, mixed mode

We should handle this better as this results in parse errors on the Quarkus side when native integration tests run. E.g.
https://github.com/graalvm/mandrel/actions/runs/9637589282/job/26577524364#step:13:2945

[jerboaa]

Note that if graal master is being built with JDK 24+3 EA, the warning doesn't happen and all should be good. So perhaps graalvm/mandrel#749 should be the actual fix for this?

[jerboaa]

$ ./mandrel-build/bin/native-image --version
native-image 24-beta 2025-03-18
OpenJDK Runtime Environment Mandrel-24.2.0-devee0e5b66ae9b (build 24-beta+3-ea)
OpenJDK 64-Bit Server VM Mandrel-24.2.0-devee0e5b66ae9b (build 24-beta+3-ea, mixed mode)

[jerboaa]

Re-opening the issue since I'm not aware we fixes the warnings handling.

[zakkak]

Indeed we don't fix the warning handling, but do we need to? The warning rightfully shows up when using an incompatible version. Do you suggest we should fail the mandrel build all together or bypass the warning and craft a version?

[jerboaa]

Indeed we don't fix the warning handling, but do we need to?

Yes, we should. It would have avoided me going down the rabbit whole of why this is happening. We'd have similar info once we notice this in the version output:

Before:

Java version: 23-beta+28-202406240955, vendor version: Mandrel-24.1.0-dev<sha>

After:

Java version: 23-beta+28-202406240955, vendor version: Mandrel-24.2.0-dev<sha>

The warning rightfully shows up when using an incompatible version. Do you suggest we should fail the mandrel build all together or bypass the warning and craft a version?

I'm arguing producing this version output isn't helpful. The warning shown on the build doesn't have sufficient info:

./mandrel-build/bin/native-image --version
native-image 23-beta 2024-09-17
OpenJDK Runtime Environment Mandrel-WARNING: Could not parse jvmci version from JVMCIVersionCheck output:-Final (build 23-beta+28-202406240955)
OpenJDK 64-Bit Server VM Mandrel-WARNING: Could not parse jvmci version from JVMCIVersionCheck output:-Final (build 23-beta+28-202406240955, mixed mode

My experiments showed that if we handled stdout/stderr output of this appropriately, we'd at least get a parsable version:

$ mx --primary-suite-path substratevm graalvm-version
WARNING: Could not parse jvmci version from JVMCIVersionCheck output:
No minimum JVMCI version specified for JDK version 23.

24.2.0-dev

Example:

$ mx --primary-suite-path substratevm graalvm-version 2>/dev/null
24.2.0-dev

We could consume the full warning output and print that after a build of mandrel. For example like so:

INFO [build] Congratulations you successfully built Mandrel 24.2.0-dev<sha> based on Java 23-beta+28-202406240955
WARNING [build] WARNING: Could not parse jvmci version from JVMCIVersionCheck output:
WARNING [build] No minimum JVMCI version specified for JDK version 23.
INFO [build] You can find your newly built native-image enabled JDK under /disk/graal/upstream-sources/graal/mandrel-build

Most solutions that come to mind would be better than the status quo, IMO.

[github-actions]

This issue appears to be stale because it has been open 30 days with no activity. This issue will be closed in 7 days unless Stale label is removed or a new comment is made.

[jerboaa]

This usually doesn't surface for release builds since they pass explicit version info using --mandrel-version <version>.