fix(ci): sync platform package versions + force local-path publish#55
Merged
Conversation
Two bugs in the build-native.yml publish job that have been latent
since the workflow was first written. Caught both during the local
0.1.2 bootstrap publish — neither would have allowed a successful
release-please-driven publish even with a working NPM_TOKEN.
1. Missing `napi version`
napi-rs scaffolds npm/<platform>/package.json files at the version
present when `napi build` first ran (here: 0.1.0). The version
field stays at that scaffolded value on every subsequent release
unless explicitly synced. Without this step, platform packages
would publish at 0.1.0 forever even as the parent package bumped.
Fix: add `npx napi version` between `napi artifacts` and the
publish loop. It reads the parent package's version and writes
it into each npm/<platform>/package.json.
2. `find ... npm publish {}` path interpretation
`npm publish npm/darwin-arm64` is interpreted as the GitHub
shorthand <user>/<repo>, not a local directory. npm tries
ssh://git@github.com/npm/darwin-arm64.git, fails with
"Permission denied (publickey)" because GHA runners have no
SSH key for github.com. Failure visible in run 25986564957.
Fix: prefix with `./` to force directory interpretation.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe publish job now runs ChangesPlatform Package Publishing
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
@napi-rs/cli v3 removed --skip-gh-release entirely. The new default behavior is "do not create a GitHub release"; opt in with --gh-release if you want one (we don't — release-please.yml owns GH release creation for both packages via its own action). Caught locally during the 0.1.2 bootstrap publish, same surface as the other two fixes in this PR.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-native.yml:
- Around line 196-198: The CI step changed the napi prepublish invocation and
unintentionally enables GitHub releases; update the run command that calls "npx
napi prepublish -t npm" to explicitly disable releases by adding the
"--no-gh-release" flag (or, if releases are intended, update the comment to
state that "--gh-release" defaults to true); specifically modify the "npx napi
prepublish -t npm" invocation to "npx napi prepublish -t npm --no-gh-release"
(and remove or correct references to the removed "--skip-gh-release" flag) so
behavior matches the comment.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 88c8aee3-84a1-480e-90ea-0e6ae048916e
📒 Files selected for processing (1)
.github/workflows/build-native.yml
Addresses PR review feedback. Previously relied on the v3 default of "no GH release" being implicit. The explicit --no-gh-release flag (clipanion-auto-generated negation of --gh-release) makes intent unambiguous so a future default flip in napi-rs can't change behavior silently. Verified the flag is accepted: dry-run exits 0 with --no-gh-release, whereas an invented flag errors with Unsupported option name. The flag doesn't appear in the --help output (clipanion only lists the positive form) but is functional.
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.
Summary
Two latent bugs in `build-native.yml`'s publish job, caught during the local 0.1.2 bootstrap publish. Neither would have allowed a successful release-please-driven publish even with a working `NPM_TOKEN` — the publish job has never actually run end-to-end.
Bug 1: missing `napi version` (platform packages stuck at scaffolded version)
napi-rs scaffolds `npm//package.json` files at the version present when `napi build` first ran (here: 0.1.0). They don't update on subsequent version bumps unless explicitly synced.
Without this step, every release would have published the platform packages at `0.1.0` forever, even as the parent package bumped to 0.1.2, 0.1.3, etc. The main `@cachekit-io/cachekit-core-ts` package would then fail to install because its `optionalDependencies` request a matching version that wouldn't exist.
Fix: `npx napi version` between `napi artifacts` and the publish loop. It reads the parent package's version and writes it into each `npm//package.json`.
Bug 2: `find ... npm publish {}` interpreted as GitHub shorthand
`npm publish npm/darwin-arm64` is interpreted as the GitHub shorthand `/`, not a local directory. npm tries `ssh://git@github.com/npm/darwin-arm64.git`, fails with `Permission denied (publickey)` because GHA runners have no SSH key for github.com.
Visible in run 25986564957 which fired on the `cachekit-core-ts-v0.1.2` tag push.
Fix: prefix `{}` with `./` to force local-directory interpretation.
Why now
Surfaced during the local-publish bootstrap script (`/tmp/publish-cachekit-0.1.2.sh`). Both bugs reproduced locally; both fixes were validated in the script. The same fixes here mean future CI-driven releases work as intended.
Interaction with #50
#50 (OIDC trusted publishing, draft) also touches the publish steps in this workflow — replacing `NODE_AUTH_TOKEN` with OIDC. When #50 is ready to come out of draft, it'll rebase onto this fix and keep both improvements.
Test plan
Summary by CodeRabbit