Repository navigation
Conversation
…stdout pnpm 11 writes its publish report to stdout and leaves stderr empty, so `error.message` - which execFileSync builds from stderr only - never contained the registry's "You cannot publish over the previously published versions" text. The guard meant to make re-runs idempotent therefore never matched, and a partially released version aborted every later release. Match against stdout and stderr as well as the message. This unblocks the stuck @visulima/task-runner release: all eight platform bindings were published at 3.0.1 on Oct 17 before the run failed at `git push --tags`, so they must be skipped for the parent package, tag and release commit to land.
|
Thank you for following the naming conventions! 🙏 |
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 1 minute. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
@semantic-release/git pushes HEAD:<branch> during prepare. When anything else lands on the branch between checkout and that push, git rejects it with "fetch first" and the release aborts: the failed package has no tag and no release commit, while its native bindings are already on npm. The push that broke the Oct 17 run was a lock-file maintenance commit that landed on main 39 seconds before the release tried to push. Keep the multi-semantic-release log and, on that specific failure, dispatch a fresh run from the new tip instead of leaving the branch red. Re-running is safe because npm and the native-addon plugin skip versions that already exist.
nx implicitDependencies only accepts project names, so listing the script there failed the project graph with "point to non-existent project(s)". Attach the file to the test target's inputs instead, which is what marks task-runner affected and reruns its tests when the plugin changes.
@visulima/task-runner
@visulima/vis
@visulima/vis-mcp
@visulima/task-runner-binding-darwin-arm64
@visulima/task-runner-binding-darwin-x64
@visulima/task-runner-binding-linux-arm64-gnu
@visulima/task-runner-binding-linux-arm64-musl
@visulima/task-runner-binding-linux-x64-gnu
@visulima/task-runner-binding-linux-x64-musl
@visulima/task-runner-binding-win32-arm64-msvc
@visulima/task-runner-binding-win32-x64-msvc
commit: |
Merging this PR will degrade performance by 12.06%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ❌ |
storeAction (1KB payload) |
7.8 ms | 8.9 ms | -12.63% |
| ❌ |
detectPm · bun workspace |
97.8 µs | 110.5 µs | -11.49% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing fix/semantic-release-already-published (a7d4351) with main (b59ffc0)
Footnotes
-
48 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
Problem
Every
Semantic Releaserun onmainsince Oct 17 fails while publishing@visulima/task-runner:@visulima/task-runneris at 3.0.0 on npm, but all eight@visulima/task-runner-binding-*packages are already at 3.0.1. Run 39075638678 published the bindings and then failed atgit push --tags, so the parent package, the tag and the release commit never landed. Every later run recomputes 3.0.1 and retries the same impossible publish.That push was rejected because a lock-file maintenance commit landed on
main39 seconds earlier:Changes
1. Recognise an already-published native addon
scripts/semantic-release-native-addons.mjsalready treats a republished version as success, but only inspectederror.message:execFileSyncbuilds that message from stderr, and pnpm 11.28.2 writes its publish report to stdout (the failed job showsstderr: ''with the E403 instdout). The guard never matched.isAlreadyPublishedError(error), which matches the conflict on the message,stdoutandstderr, and use it inprepare.EPUBLISHCONFLICT, an unrelated 401, and a non-Errorrejection.task-runnerso changing it runs the package tests.2. Recover from a rejected release push
@semantic-release/gitpushesHEAD:<branch>from inside the release. Any push landing between checkout and that push aborts the release with the failed package untagged. The workflow now keeps themulti-semantic-releaselog and, when that failure is a rejected push and the branch has moved since the run started, dispatches a fresh run from the new tip. Re-running is safe because npm and the native-addon plugin skip versions that already exist.Effect
On the next release run the eight burnt bindings are skipped,
@visulima/task-runner@3.0.1publishes, and the tag/release commit complete —mainstops failing. Future mid-release pushes self-heal with one fresh run instead of staying red.Verification
vitest run __tests__/unit/semantic-release-native-addons.test.ts— 5 passedeslinton the new test — cleanprettier --checkon all changed files — cleanactionlint .github/workflows/semantic-release.yml— cleanzizmor— only the pre-existingself-repositoryfinding, unrelated to this change