Repository navigation
馃敡 build(deps): provision JDKs with mise, lock and auto-update - #264
Merged
Merged
Conversation
Java setup was duplicated across every CI job (distribution/version pairs in five check.yaml steps and two release.yaml steps) and undocumented locally - CONTRIBUTING.md said "you'll need JDK 21" with no mention of the JDK 17 the Kotlin jvmToolchain also needs, which Gradle could only find by auto-downloading or by luck of what's already on the machine. mise.toml pins zulu-21 (runs Gradle) and zulu-17 (jvmToolchain target) for both contexts, and mise.lock records resolved versions and checksums per platform so a local macOS dev and the Linux CI runner install byte-identical JDKs. Gradle doesn't auto-detect mise-managed installations, so gradle.properties points it at the JDK17 env var mise exports via mise.toml's own env block, resolved through the "zulu-17" alias symlink mise maintains so it keeps working across lockfile bumps without touching gradle.properties again. Verified end to end with a clean environment carrying only mise's exports. Both CI workflows swap actions/setup-java for jdx/mise-action, which installs from the lockfile and exports the same JDK17 variable. Caching is off in release.yaml, since that workflow runs on a release-publish event and zizmor flags cache writes there as a poisoning risk. A new weekly workflow runs `mise lock --bump` and opens a PR when the resolution changes, the pattern mise's own docs describe for this. Dependabot has no mise/asdf ecosystem to do this instead.
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
1 participant
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.
Java setup was duplicated across every CI job, five steps in
check.yamland two inrelease.yaml, each repeating the same distribution and version. Locally it was undocumented:CONTRIBUTING.mdsaid "you'll need JDK 21" with no mention of the JDK 17 that the KotlinjvmToolchainalso needs, which Gradle could only satisfy by auto-downloading or by whatever happened to already be on the machine.mise.tomlpinszulu-21(runs Gradle) andzulu-17(the toolchain target) for both contexts, andmise.lockrecords the resolved version and checksum per platform, so a local macOS checkout and the Linux CI runner install byte-identical JDKs. Gradle doesn't auto-detect mise-managed installations, sogradle.propertiespoints it at aJDK17environment variable thatmise.toml's own[env]block exports, resolved through thezulu-17alias symlink mise maintains so it keeps working across lockfile bumps without anothergradle.propertiesedit. I verified this end to end in a shell carrying only mise's exports, no ambientJAVA_HOMEor PATH.Both workflows swap
actions/setup-javaforjdx/mise-action, which installs from the lockfile and exports the sameJDK17variable. Caching is off inrelease.yaml, since that workflow runs on a release-publish event and zizmor flags cache writes there as a poisoning risk.A new weekly workflow runs
mise lock --bumpand opens a PR when the resolution changes, the update pattern mise's own docs describe for this. Dependabot has no mise/asdf ecosystem to do it instead.