Conversation
Follows rundeck and rundeckpro onto Java 25. The Gradle wrapper goes to 9.6.0, the Java source/target moves to 25 where this build declares it, and the workflows that run the build move with it -- a build targeting 25 is no use if CI still hands it a 17 JVM. The functional-test module needed one more thing: its specs run through the functionalTest task, which needs Docker, so the default test task has those sources on its source set but nothing it can discover. Gradle 9 treats that as a misconfiguration and fails, so that task sets failOnNoDiscoveredTests = false. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Points at the core built from the Grails 8 / Java 25 branch, which is where this plugin will run. Gradle's module metadata enforces this: core 7.0.0 declares a JVM version of 25, so a consumer still asking for 17 is rejected outright at resolution -- "only compatible with JVM runtime version 25 or newer" -- rather than failing later. Note this does not resolve from a remote repository yet. 7.0.0-SNAPSHOT is produced by a normal (non-tag) rundeck build and only exists where that build has run publishToMavenLocal. CI will not find it until core publishes a snapshot somewhere reachable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…NAPSHOT A released rundeck-core resolves from Maven Central like any other dependency. A SNAPSHOT only exists where it was built, so CI has nothing to resolve: build it from source into the local Maven repository first. The branch cannot be inferred. A SNAPSHOT coordinate carries no branch identity, so rundeckCoreBranch goes in gradle.properties, beside the dependency it describes and versioned with it. The version is read from the declared dependency rather than parsed out of a build file. Across the plugin set this dependency is spelled four different ways -- version catalog, ext property, inline coordinate, named arguments -- and the declared-dependency model is identical for all of them. Reading it resolves nothing, so it works before the core has been built. Artifacts are cached on the core commit and the wanted version together. Keying on the commit alone would turn a version bump into a cache hit that skips the guard, surfacing as an opaque "not found" during the plugin build instead of the explicit mismatch error. Also corrects the JDK step label, which still read 17 while setting up 25. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Releasing an alpha needs the rundeck-core SNAPSHOT built from source first, the same bootstrap gradle.yml already uses. Keeping that out of release.yml leaves the path that cuts real releases untouched. That only works if the two triggers are disjoint. release.yml fires on '*.*.*', which also matches 2.0.6-alpha1 -- both workflows would run on one tag push, and the second gh release create would fail on a tag that already has a release. So release.yml now excludes alpha tags explicitly. The alpha workflow is release.yml plus the bootstrap, publishing to the same places and marking the GitHub release as a prerelease. The bootstrap block is taken from gradle.yml rather than rewritten, so the two cannot drift. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ltamaster
force-pushed
the
grails-8-upgrade
branch
from
September 17, 2026 01:23
25065b9 to
2941171
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Follows
rundeckandrundeckproonto Java 25. One of 23 plugin repos moving together; the change is the same in each.java-versionThe workflows move with the build deliberately: a build targeting 25 is no use if CI still hands it a 17 JVM.
One extra change. The
functional-testmodule's specs run through thefunctionalTesttask (which needs Docker), so the defaulttesttask has those sources on its source set but nothing it can discover. Gradle 9 treats that as a misconfiguration and fails the build, so that task now setsfailOnNoDiscoveredTests = false.Testing
./gradlew clean buildpasses on JDK 25 (Zulu 25.0.4).Not verified here: publishing, and the plugin running inside a Rundeck instance.