Started by upstream project "Lucene-main-Windows" build number 21,09421094Lucene-main-Windowsjob/Lucene-main-Windows/6358156589e3eda36bec0b2b146dc1af283c62be1806156589e3eda36bec0b2b146dc1af283c62be1806refs/remotes/origin/branch_10x156589e3eda36bec0b2b146dc1af283c62be1806156589e3eda36bec0b2b146dc1af283c62be1806refs/remotes/origin/branch_10x156589e3eda36bec0b2b146dc1af283c62be1806156589e3eda36bec0b2b146dc1af283c62be1806refs/remotes/origin/branch_10xhttps://gitbox.apache.org/repos/asf/lucene.git0147920239testReportfalseJava: 64bit/hotspot/jdk-21.0.12 -XX:+UseCompressedOops -XX:+UseSerialGC#6358710676808537Lucene-10.x-macOS #63586358falsefalse6358235505SUCCESS1791411363140https://jenkins.thetaphi.de/view/Lucene/job/Lucene-10.x-macOS/6358/macOS VM.github/workflows/run-checks-all.yml156589e3eda36bec0b2b146dc1af283c62be18061791408887000https://jenkins.thetaphi.de/user/rmuirRobert Muirrmuir@apache.orgci: run checks-without-tests on highest supported java version too (#16789) The gradle build supports a range of java versions. When a new java version is released, there is usually some amount of work before everything "really works" on that version. For example spotless and other components that are tightly-coupled with the JDK. It is a bit error-prone today since you have to run various workflows locally to know you have it really correct. If we test the upper-bound (newest supported version) too, the CI can help us. This will cost a few minutes per build (cpu time, not wall-clock), but it can give us more confidence when reviewing dependabot PRs, or bumping JDK versions. 2026-10-07 17:34:47 -0400156589e3eda36bec0b2b146dc1af283c62be1806ci: run checks-without-tests on highest supported java version too (#16789)edit.github/workflows/run-checks-all.ymlgithttps://jenkins.thetaphi.de/user/rmuirRobert Muir