Hi, first of all, thank you for maintaining this action. I've been using it and noticed that anyone pinned to v2.0.1 is getting Node 20 deprecation warnings since that runtime is now EOL, even though master already has the Node 20 -> 24 upgrade merged.
The root cause is that dist/index.js (the ncc bundle that runners execute directly) isn't rebuilt when Renovate merges dependency updates. So v2.0.1 still ships the old bundle, and master has a stale dist/ too.
I've been exploring this in my fork and put together three small, additive proposals, none of which change any existing behavior:
1. Non-blocking dist/ staleness check in CI (test.yml)
Adds a warning annotation + step summary when dist/ doesn't match a clean build. Exits 0 always, so Renovate auto-merges are unaffected.
2. build.yml - manual workflow to rebuild and commit dist/
Triggered manually on any branch. Runs npm ci && npm run all, commits dist/ back via GITHUB_TOKEN if changed (idempotent). Solves the stale bundle problem without adding automation.
3. publish.yml - manual workflow to cut a draft release
Triggered manually with a version input. Hard-fails if dist/ is stale (prompting you to run build.yml first), then bumps package.json, tags, and creates a draft GitHub Release for your review before publishing.
I've proven all three working end-to-end on my fork, including the a. hard-fail -> b. Build dist/ -> c. Publish draft release flow.
See example here:
a. hard-fail
b. Build dist/
c. Publish draft release
The new workflow files use pinned action hashes following the same
convention as the existing workflows - I assume Renovate will maintain them
automatically with no additional configuration needed.
Happy to open separate PRs for any or all of these if you're interested.
Keeping them separate makes each one easy to review and accept independently.
I've also published v3.0.0 internally in my fork, to unblock my team, but I look forward to helping you automate more of the release cycle for this nice project. Happy to chat if you want.
Let me know if you feel like going in other directions or if something else is on your mind.
Hi, first of all, thank you for maintaining this action. I've been using it and noticed that anyone pinned to
v2.0.1is gettingNode 20deprecation warnings since that runtime is now EOL, even thoughmasteralready has the Node20->24upgrade merged.The root cause is that
dist/index.js(thenccbundle that runners execute directly) isn't rebuilt whenRenovatemerges dependency updates. Sov2.0.1still ships the old bundle, andmasterhas a staledist/too.I've been exploring this in my fork and put together three small, additive proposals, none of which change any existing behavior:
1. Non-blocking
dist/staleness check in CI (test.yml)Adds a warning annotation + step summary when
dist/doesn't match a clean build. Exits0always, soRenovateauto-merges are unaffected.2. build.yml - manual workflow to rebuild and commit
dist/Triggered manually on any branch. Runs
npm ci && npm run all, commitsdist/back viaGITHUB_TOKENif changed (idempotent). Solves the stale bundle problem without adding automation.3. publish.yml - manual workflow to cut a draft release
Triggered manually with a
versioninput. Hard-fails ifdist/is stale (prompting you to runbuild.ymlfirst), then bumpspackage.json, tags, and creates adraftGitHub Release for your review before publishing.I've proven all three working end-to-end on my fork, including the
a. hard-fail->b. Build dist/->c. Publish draft releaseflow.See example here:
a. hard-fail
b. Build dist/
c. Publish draft release
Happy to open separate PRs for any or all of these if you're interested.
Keeping them separate makes each one easy to review and accept independently.
I've also published v3.0.0 internally in my fork, to unblock my team, but I look forward to helping you automate more of the release cycle for this nice project. Happy to chat if you want.
Let me know if you feel like going in other directions or if something else is on your mind.