Restore Java 21 CI compatibility check - #928
Conversation
…27-050400-74f7e6bf - Upgrade Gradle wrapper to 9.5.1 - Replace com.gradle.enterprise with com.gradle.develocity plugin - Upgrade net.researchgate.release to 3.1.0 for Gradle 9 compatibility - Replace all deprecated buildDir references with layout.buildDirectory - Replace Project.exec() calls with ExecOperations injection pattern - Remove deprecated sourceCompatibility/targetCompatibility (replaced by toolchain) - Add Java 25 toolchain to all Java subprojects - Upgrade Ballerina Gradle plugin to 4.0.0 (Java 25 + Gradle 9.5.1 compatible) - Update ballerinaLangVersion to 2201.14.0-20260527-050400-74f7e6bf - Update all platform.java21 TOML sections to platform.java25 - Add patchBallerinaScripts task to fix bal binary permissions and remove --sun-misc-unsafe-memory-access=allow flag (removed in Java 25) - Upgrade SpotBugs Gradle plugin to 6.5.1 for Java 25 class file support - Add SpotBugs exclusions for THROWS/AT/USELESS_STRING/DM detectors introduced in SpotBugs 4.9.x (bundled in plugin >= 6.2.0) - Update CI workflow to use pull-request-build-template.yml@java-25-migration
Applied fixes: B3, B5+C1 - Make patchBallerinaScripts idempotent and add task @input properties (A1, B1) - Use token-level JVM flag removal instead of line filter (B4) - Remove mavenLocal() from plugin repositories (A4) - Scope SpotBugs suppressions to module packages (A5) - Add Gradle wrapper integrity checksum (B3) - Wire jacocoVersion property to JaCoCo toolVersion (B5) - Bump JaCoCo to 0.8.14 for stable Java 25 support (C1)
… build-config (D6)
…s task The PatchBallerinaScriptsTask abstract class computes bin paths internally in its @TaskAction method. The previous commit mistakenly added jballerinaToolsBinPath and ballerinaRuntimeBinPath assignments in the task registration block, but these are not declared as @input properties on the class. Gradle 9.5.1 strict property model rejects unknown property assignments with: Could not set unknown property 'jballerinaToolsBinPath'. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ipts These forced all builds onto JDK25 regardless of the JAVA_HOME the build was invoked with, breaking genuine JDK21 builds. The scripts now only fix executable permissions on the unpacked bal binaries and otherwise stay JDK-independent.
|
Warning Review limit reached
Next review available in: 47 seconds Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (12)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
Codecov Report✅ All modified and coverable lines are covered by tests. ❌ Your project check has failed because the head coverage (79.48%) is below the target coverage (80.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## master #928 +/- ##
============================================
- Coverage 81.00% 79.48% -1.53%
Complexity 171 171
============================================
Files 21 21
Lines 1111 931 -180
Branches 181 144 -37
============================================
- Hits 900 740 -160
+ Misses 127 107 -20
Partials 84 84 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
1 participant
Purpose
This branch is derived from
java-25-mig-wo-java-change(#927) with one additional change: it reverts.github/workflows/pull-request.ymlback tomaster, restoring the original PR-build workflow (which runs CI against JDK 21) instead of pointing at thejava-25-migrationbranch of the reusable build template.All other build/config migration changes (Gradle 9.5.1 upgrade, Java 25 toolchain settings, checkstyle/spotbugs config, etc.) from
java-25-mig-wo-java-changeare kept as-is.The purpose of this branch is to verify that the Gradle/build migration changes still pass CI under Java 21, independent of the Java 25 toolchain switch.