force the use jdk21 through Crave
https://issues.apache.org/jira/browse/SOLR-XXXXX
Description
The Solr project is considering the usage of JDK 21 at some point.
We need to control which JDK is used in Crave.
Solution
A crave.yaml file at the top of the source repository is read by Crave to override any Crave defaults.
This change introduces the file, with the image override for JDK 21.
Tests
I ran the following command on my private branch with this file and against the upstream Solr, and saw that the new JDK has been used with this change.
Before change: https://foss.crave.io/app/#/build/info/109405?team=5
javac 11.0.23
After change: https://foss.crave.io/app/#/build/info/109418?team=5
javac 21.0.3
Full log output:
14:15:01 admin@Uv-MacAir:/crave-devspaces/solr/uvatbc$ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
14:20:18 admin@Uv-MacAir:/crave-devspaces/solr/uvatbc$ crave run -- javac --version
Selecting project Solr (id:39)
Picking up local changes (if any)...
Waiting for build id:109405 to start...
Error: Could not start service links, since job is no longer running
Setting up workspace (this could take some time)...
Pulling container image accupara/openjdk:11...
Finished pulling container image accupara/openjdk@sha256:4f56da3bde6640dcff1440d8429ec770d44f3d94985a2eb3d2253ed1885f9933 took 977.339733ms
using branch "main"
setting commitID to 31e85fb6d87d2f70e92501d4df065d0c9ed3a466
javac 11.0.23
------------------------------------------------------------------------
Build Successful
Total time: 18s
------------------------------------------------------------------------
Build logs saved at: https://foss.crave.io/app/#/build/info/109405?team=5
14:23:35 admin@Uv-MacAir:/crave-devspaces/solr/uvatbc$ git checkout crave-jdk-21
Switched to branch 'crave-jdk-21'
15:06:07 admin@Uv-MacAir:/crave-devspaces/solr/uvatbc$ crave run -- javac --version
Selecting project Solr (id:39)
Picking up local changes (if any)...
1 file changed, 2 insertions(+)
Waiting for build id:109418 to start...
Error: 2024/06/05 15:10:36 client: Connection error: server: access to port 10.128.15.194:7091:3 denied err: <nil>
Error: 2024/06/05 15:10:37 client: Connection error: server: access to port 10.128.15.194:7546:3 denied err: <nil>
Services in this job can be accessed using the following:
Service Remote Access URL
--------- -------- ------------------------
ssh 22 ssh://localhost:40279
vscode 5899 vscode://localhost:39035
Setting up workspace (this could take some time)...
Pulling container image accupara/openjdk:21...
Finished pulling container image accupara/openjdk@sha256:903dbc01cdd18791ffd4a8ee710f5a7f499bd664fd9ee85a42f7f548c41aabce took 12.942741237s
Switched to a new branch 'crave-jdk-21'
setting commitID to 31e85fb6d87d2f70e92501d4df065d0c9ed3a466
From /home/admin/.craved/mcduSuBhHKKD-8a8cf14e400f0b9cf5fc12fd7d51bb83ea225229.patch.gz.b64
* branch HEAD -> FETCH_HEAD
Updating 31e85fb6d87..9fa39c70e56
Fast-forward
crave.yaml | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 crave.yaml
javac 21.0.3
------------------------------------------------------------------------
Build Successful
Total time: 31s
------------------------------------------------------------------------
Build logs saved at: https://foss.crave.io/app/#/build/info/109418?team=5
Checklist
Please review the following and check all that apply:
- [x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
- [ ] I have created a Jira issue and added the issue ID to my pull request title.
- [x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
- [x] I have developed this patch against the
mainbranch. - [ ] I have run
./gradlew check. - [x] I have added tests for my changes.
- [ ] I have added documentation for the Reference Guide
I tried running this for #2497 (https://foss.crave.io/app/#/build/info/109489?team=5)
BUILD SUCCESSFUL in 7m 25s 141 actionable tasks: 114 executed, 27 up-to-date
I wonder If this setting can be added to test-via-crave.yml rather than creating a separate file.
Before this change here, isn't there some existing build image for Solr you @uvatbc worked on ?
@iamsanjay assuming the build starts running on JDK 21 (wherever -- CI / Crave / dev machine, wherever), should it pass in your experience? There are "flapper"/intermittent failures here & there but does it at least seem sound as-is? Locally I'm not the best judge on my machine as I have a company provided JDK with some differences.
If crave.yml change the Java version to 21, gradlew check should fail, more specifically the ecj-lint version that we are currently using make sure the Java version should be less than or equal to 19.
Task :solr:api:ecjLintMain FAILED source level should be in '1.1'...'1.8','9'...'19' (or '5.0'..'19.0'): 21
And, dependancy-analyze task should also fail which we have disabled in #2497 just to make it run.
Task :solr:modules:scripting:analyzeTestClassesDependencies Dependency analysis found issues. unusedDeclaredArtifacts
- org.apache.solr:test-framework:10.0.0-SNAPSHOT@
This PR has had no activity for 60 days and is now labeled as stale. Any new activity or converting it to draft will remove the stale label. To attract more reviewers, please tag people who might be familiar with the code area and/or notify the [email protected] mailing list. Thank you for your contribution!
If crave.yml change the Java version to 21,
gradlew checkshould fail, more specifically theecj-lintversion that we are currently using make sure the Java version should be less than or equal to 19.
Ok let me check again.
@uvatbc thanks for offering to help further (edit our build) if you wish but I wouldn't want any feedback on these PRs to be implied that it is for you to update our build. You give us Crave.io build machines for free, which is tremendous! It's up to one of us committers or a volunteer to make the build Java 21 compliant.
@iamsanjay as this just adds a file, maybe you should simply include it in #2682 as you are touching other CI files there as well so why not.
Oh nevermind; it's already there :-) I'll close this PR; thanks @uvatbc