ci: move workflow actions off the deprecated Node 20 runtime - #48
Open
foureight84 wants to merge 1 commit into
Open
ci: move workflow actions off the deprecated Node 20 runtime#48foureight84 wants to merge 1 commit into
foureight84 wants to merge 1 commit into
Conversation
The v2.5.0+35 release run warned that checkout@v4, setup-java@v4, setup-gradle@v4 and action-gh-release@v2 all target Node 20 and were being force-run on Node 24, and that setup-java v4 is EOL. Builds still pass, but the forced-migration window closes eventually. actions/checkout v4 -> v7 actions/setup-java v4 -> v5 gradle/actions/setup-gradle v4 -> v5 (not v6 — see below) actions/upload-artifact v4 -> v7 softprops/action-gh-release v2 -> v3 Every one of these majors is a Node 20 -> 24 runtime bump; none changes an input this repo passes. checkout v7 also blocks fork checkouts for pull_request_target and workflow_run, neither of which these workflows use. upload-artifact v7 adds an optional `archive` input and leaves name/path/if-no-files-found/retention-days untouched. All require runner >= 2.327.1, which GitHub-hosted ubuntu-latest is well past. **setup-gradle deliberately stops at v5, not the latest v6.** v6 extracts caching into `gradle-actions-caching`, a proprietary component governed by Gradle's commercial Terms of Use instead of the MIT licence, and using v6 with caching enabled accepts those terms. v5 is the last MIT line and already runs on Node 24, so it fully resolves the deprecation without taking on a licensing commitment on behalf of an OSS project. Both workflows carry a comment saying so, with a link to Gradle's blog post, so the next person doesn't "helpfully" bump it. Note this PR exercises ci.yml only — release.yml runs on tag pushes, so its changes stay unverified until the next release tag.
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.
The
v2.5.0+35release run warned that four actions target Node 20 and are being force-run on Node 24, and thatsetup-javav4 is EOL. Builds pass today; this closes it out before the forced-migration window does.actions/checkoutactions/setup-javagradle/actions/setup-gradleactions/upload-artifactsoftprops/action-gh-releaseEvery one of these majors is a Node 20 → 24 runtime bump. I read the release notes for each; none changes an input this repo passes. Specifically:
pull_request_targetandworkflow_run— neither workflow uses those events (CI is onpull_request).archiveinput and leavesname/path/if-no-files-found/retention-daysuntouched.ubuntu-latestis well past that.gradle/actions@v6extracts caching intogradle-actions-caching, a proprietary component governed by Gradle's commercial Terms of Use rather than the MIT licence — and per Gradle's own blog post, upgrading to v6 accepts those terms when caching is enabled.v5 is the last MIT line and already runs on Node 24, so it fully resolves the deprecation without taking on a licensing commitment on behalf of an OSS project. That felt like your call rather than mine, so I took the option that doesn't foreclose it. Both workflows carry a comment explaining why, with the blog link, so this doesn't get "helpfully" bumped later without the context.
Moving to v6 is a one-line change if you'd rather have the newer caching.
Verification
Workflow YAML parses cleanly with the expected structure (ci: 1 job / 6 steps; release: 1 job / 8 steps). The real check is CI on this PR.
Caveat: this PR exercises
ci.ymlonly.release.ymlruns on tag pushes, so its changes stay unverified until the next release tag — worth knowing if the next release is time-sensitive. The changes are identical in kind to the ones CI does cover.