feat(actions): npm-publish-hardened accepts multi-tarball input#30
Conversation
Adds a `tarballs` input (newline-separated paths) alongside the
existing singular `tarball`. Exactly one of the two must be set.
When `tarballs` is used, the action publishes each tarball
sequentially with the same per-tarball semantics — idempotent
`npm view` early-return, 5-attempt retry with backoff, final
eventual-consistency poll. Order matters: a napi-rs meta-package
depends on its platform sub-packages being published first, so the
caller controls ordering by listing platform tarballs before root.
The three napi-rs publishing repos (regex-set, aho-corasick,
fuzzy-search) currently pack 1 root + N platform tarballs and
publish them via an inline bash loop. The new input lets each repo
collapse that whole step into a single composite invocation passing
both `${{ steps.pack.outputs.aux_tarballs }}` (the newline-separated
list) and the root tarball.
The existing singular `tarball` input keeps working unchanged —
stdnum and text-search migrations don't need to be touched.
Tested locally across 7 cases: single mode, multi mode, both-set
error, neither-set error, blank-line filtering, missing-file error,
multi success path.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request extends the npm-publish-hardened action to support publishing multiple tarballs by introducing a tarballs input and refactoring the publish.sh script to process a queue of tarballs sequentially. The refactor includes improved pre-validation and a modular publish_one function. The reviewer suggested updating the action.yml description to more accurately reflect that one of the two inputs is required for a successful execution.
| required: true | ||
| description: > | ||
| Path to a pre-packed .tgz to publish. Mutually exclusive with | ||
| `tarballs` — exactly one of the two must be set. |
There was a problem hiding this comment.
The description states "exactly one of the two must be set". However, since both tarball and tarballs are required: false, it's possible to set neither. While the script handles this case correctly by exiting with an error, the action's input description is misleading for users. It would be clearer to state that one of the two inputs is functionally required for a successful run.
`tarballs` — one of `tarball` or `tarballs` must be set.Addresses gemini medium on PR #30.
|
CC on behalf of @jan-kubica — applied. Both descriptions now spell out that the inputs are alternatives where one must be set, not optional inputs. |
1 participant
Why
The three napi-rs publishing repos (`regex-set`, `aho-corasick`, `fuzzy-search`) pack 1 root tarball + N platform tarballs and publish them via an inline bash loop. The composite previously only accepted a single tarball, so a 1:1 migration would need 6–8 discrete steps per repo with dynamic tarball filenames the pack step can't expose statically.
This PR adds a `tarballs` (plural) input that accepts a newline-separated list. The action publishes each tarball sequentially with the same per-tarball semantics — idempotent `npm view` early-return, 5-attempt retry with backoff, final eventual-consistency poll.
Order matters: a napi-rs meta-package depends on its platform sub-packages being on the registry first. The caller controls ordering by listing platform tarballs before root in the input.
Backwards compatibility
The existing singular `tarball` input keeps working unchanged. `stdnum` and `text-search` migrations don't need to be touched.
`tarball` and `tarballs` are mutually exclusive — setting both is an error.
Test plan