Repository navigation
Prepare v2.1.0: changelog, Node.js setup hardening, and a floating major tag - #14
Merged
Merged
Conversation
Add a retroactive CHANGELOG.md covering every release and move the changelog out of README.md. Resolve the node-version input through resolve-node-version.sh so a bare 'lts', 'lts/' or 'lts/latest' becomes 'lts/*' instead of failing setup-node, skip the Node.js setup entirely when npm dependencies are not being upgraded, and upgrade actions/setup-node from v3 to v7 with package-manager-cache disabled. Add a workflow that repoints the major version tag at each published stable release so @v2 resolves to the newest 2.x release.
mogmarsh
approved these changes
Sep 18, 2026
| MAJOR_TAG="${RELEASE_TAG%%.*}" | ||
|
|
||
| git config user.name 'github-actions[bot]' | ||
| git config user.email '41898282+github-actions[bot]@users.noreply.github.com' |
Member
Author
There was a problem hiding this comment.
eh it'll be fine I guess
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.
Summary
Release prep for v2.1.0, which packages the pull request reuse work from #13 along with fixes for the failure in this mantle run.
CHANGELOG.mdcovering every release from 1.0.0 through 2.1.0, and replace the inline changelog inREADME.mdwith a link to it.node-versioninput through a newresolve-node-version.shso a barelts,lts/, orlts/latestbecomeslts/*with a warning instead of failingsetup-node.upgrade-npm-dependenciesis"false", so workflows that only bump theTested up toheader have no dependency onactions/setup-nodeat all.actions/setup-nodefrom v3 to v7, withpackage-manager-cache: false.Update Major Version Tagworkflow so thev2tag repoints at each published stable release.What actually broke in that mantle run
Worth stating plainly, because it is not what the error message suggests. mantle's workflow does not pass
node-versionat all — it pinsalleyinteractive/action-update-wordpress-plugin@v2.0.0, andltsis that version's own default. v2.0.1 already fixed the default tolts/*, so the real root cause is the pin, not a missing feature.That means three separate things have to be true for this class of failure to stop recurring, and this PR covers the first two:
ltsis still what the v2.0.0 README tells people to write, so anyone who copied that example hits the same wall even on a current release. The action now rewrites it and logs a warning rather than failing.@v2consumers get fixes automatically. Thev2release description already says "A pointer to the latest release in the 2.x.x version," but the tag has been stale at v2.0.0 since April 2025. The new workflow keeps it current on every published stable release.@v2. That is a change in the mantle repo, not this one. Happy to open it separately.The other failure in that same log
The run also emitted
Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: actions/checkout@v3, actions/setup-node@v3. That is a warning today and a hard failure once GitHub finishes the removal, soactions/setup-nodemoves from v3 to v7 here.Two consequences of that jump are worth reviewing:
package-manager-cache: falseis deliberate. setup-node v5 began caching automatically whenpackage.jsondeclares apackageManagerfield. Left on, that would reintroduce exactly thenpm cifailure fixed back in 1.0.2 for plugins without apackage-lock.json. Disabling it preserves the existing behavior.README.mdand the changelog entry.Making Node.js optional
Per discussion on this branch, the
resolve-node-versionandsetup-nodesteps are now both gated oninputs.upgrade-npm-dependencies != 'false'. The action only needs Node.js to runnpm ciandwp-scripts packages-update, so a workflow that just bumps theTested up toheader now touches no Node.js tooling whatsoever and cannot fail on a version string. This does not help mantle specifically, since mantle passesupgrade-npm-dependencies: "true", but it removes the failure mode for everyone who does not need the npm work.On the major version tag
The workflow triggers on
release: published, skips prereleases and any tag that is notvX.Y.Z, derives the major from the tag, and force-pushes it as an annotated tag. One thing to be aware of: there is an existing GitHub release namedv2, and force-moving the tag will make that release point at the new commit. That is the behavior its description asks for, but the release will look like it changed. Say the word if you would rather delete thev2release and keep only the tag.Testing
./tests/check-upgrade.sh— 14 tests, all passing./tests/resolve-node-version.sh— 18 new tests, all passing, coveringlts,LTS,lts/,lts/latest, surrounding whitespace, empty input, and pass-through oflts/*,lts/jod,20,20.11.1, andlatestshellcheckacrosscheck-upgrade.sh,resolve-node-version.sh, both test suites, and every stub — cleanaction.ymland both workflow filesBoth suites now run in the existing CI workflow, whose
actions/checkoutalso moves from v3 to v5.Follow-up after merge
Publishing the v2.1.0 release will exercise the new workflow and move
v2to it. The very first move still has to be done by hand, since the workflow does not exist on the tag being released — I can run that force-push once you publish, or you can.