feat(core): move release to use Graal CE JDK#6390
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe pull request migrates JDK infrastructure from standard Java 17 and Apache Corretto to GraalVM Community Edition 17.0.9 across the CI/CD pipeline and Docker build configuration, including platform-specific installation steps and Maven configuration updates. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Possibly related PRs
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@CodeRabbit review this move from corretto JDK 17 to Graal CE 17. This change focused on the release artefacts. When release is shipped, it will be done with Graal after this change is merged |
|
@bluestreak01: I'll review the migration from Corretto JDK 17 to Graal CE 17 for your release artifacts. I'll examine:
I can see from your PR objectives that the CI build and Docker container are working successfully. Let me analyze all the changes in detail. ✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
ci/github-release-pipeline.yml (1)
3-3: Consider centralizing GraalVM version to reduce duplication.The GraalVM version
17.0.9is hardcoded in three locations (Dockerfile line 3, Linux install line 40, Windows install line 54). Future version updates require changes in multiple places.If versioning flexibility becomes important, consider moving this to a pipeline variable or a
.env/ configuration file that both Docker and CI can reference.Also applies to: 40-40, 54-54
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
ci/github-release-pipeline.yml(1 hunks)core/Dockerfile(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (37)
- GitHub Check: Github Binaries Release (Release binaries to github Release)
- GitHub Check: New pull request (Coverage Report Coverage Report)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-other)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-pgwire)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-cairo-sub)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-cairo-root)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-fuzz2)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-fuzz1)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-griffin-sub)
- GitHub Check: New pull request (SelfHosted Other tests on linux-x86-graal)
- GitHub Check: New pull request (SelfHosted Other tests on linux-arm64)
- GitHub Check: New pull request (SelfHosted Other tests on linux-x64-zfs)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-griffin-root)
- GitHub Check: New pull request (SelfHosted Griffin tests on linux-x64-zfs)
- GitHub Check: New pull request (Hosted Running tests on windows-other-2)
- GitHub Check: New pull request (Hosted Running tests on windows-other-1)
- GitHub Check: New pull request (Hosted Running tests on windows-pgwire)
- GitHub Check: New pull request (Hosted Running tests on windows-cairo-2)
- GitHub Check: New pull request (Hosted Running tests on windows-cairo-1)
- GitHub Check: New pull request (Hosted Running tests on windows-fuzz2)
- GitHub Check: New pull request (Hosted Running tests on windows-fuzz1)
- GitHub Check: New pull request (Hosted Running tests on windows-griffin-sub)
- GitHub Check: New pull request (Hosted Running tests on windows-griffin-base)
- GitHub Check: New pull request (Hosted Running tests on mac-other)
- GitHub Check: New pull request (Hosted Running tests on mac-pgwire)
- GitHub Check: New pull request (Hosted Running tests on mac-cairo-fuzz)
- GitHub Check: New pull request (SelfHosted Griffin tests on linux-x86-graal)
- GitHub Check: New pull request (Hosted Running tests on mac-cairo)
- GitHub Check: New pull request (SelfHosted Cairo tests on linux-x86-graal)
- GitHub Check: New pull request (Rust Test and Lint on linux-jdk17)
- GitHub Check: New pull request (Hosted Running tests on mac-griffin)
- GitHub Check: New pull request (SelfHosted Cairo tests on linux-x64-zfs)
- GitHub Check: New pull request (SelfHosted Griffin tests on linux-arm64)
- GitHub Check: New pull request (SelfHosted Cairo tests on linux-arm64)
- GitHub Check: Github Binaries Release (Building Binaries on Azure workers windows)
- GitHub Check: Github Binaries Release (Building Binaries on Azure workers linux-jdk17)
- GitHub Check: New pull request (Check Changes Check changes)
🔇 Additional comments (5)
core/Dockerfile (2)
7-11: Clean consolidation of base tools and Maven installation.The consolidation of package installation into a single RUN command with proper cleanup is good practice. Maven is now sourced from the system package manager rather than tied to the Corretto repository.
22-23: JAVA_HOME and PATH configuration is correct.The environment variables are properly set to enable the GraalVM JDK throughout the build and runtime stages.
ci/github-release-pipeline.yml (3)
74-81: Maven task correctly references GraalVM installation.The Maven task is properly configured to use the custom-installed GraalVM via
javaHomeOption: 'Path'andjdkDirectory: '$(GRAALVM_HOME)', which allows the pipeline to use the GraalVM JDK installed in the earlier steps.
1-81: Verify GraalVM CE licensing and release artifact compatibility.This PR limits GraalVM Community Edition to the release pipeline only; test workflows remain unchanged and use Temurin JDK 17. Since the release pipeline intentionally skips tests (
-DskipTests), the concern about full test suite passing is out of scope for this specific change.However, confirm before merge:
- GraalVM Community Edition licensing is compliant with QuestDB's distribution model
- Release artifacts built with GraalVM CE are functionally equivalent to prior Corretto-built releases
52-71: The Windows zip structure assumption is documented and valid; the core concern in this review is unfounded.GraalVM Windows ZIP unpacks to a single top-level directory named for that build (pattern: graalvm-ce-java-), containing the standard JDK/GraalVM layout. The Windows script's assumption on line 66 (
Get-ChildItem $dest | Where-Object { $_.PSIsContainer }) aligns with this documented behavior.The diff's defensive null check would be optional good practice, but the script correctly handles the documented structure. Additionally, the pipeline does not use checksum verification anywhere else for third-party downloads, so suggesting it only for Windows is inconsistent. The SHA256 hash in the diff is also a placeholder and not a real value.
Likely an incorrect or invalid review comment.
Release CI works: https://dev.azure.com/questdb/questdb/_build/results?buildId=194946&view=results
Docker: