fix(ci): create the pack destination before npm pack - #17
Merged
Conversation
`npm pack --pack-destination ./release-artifact` fails with ENOENT when the directory does not exist — npm writes the tarball there but never creates the path. The v2.0.1 tag hit this on the first real run of the pipeline: verify built and tested cleanly, then died at the pack step, so publish never ran. Reproduced locally: packing into a missing directory ENOENTs, packing into one created first succeeds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes the release workflow’s verify job so npm pack --pack-destination can successfully write the publishable tarball by ensuring the destination directory exists first. This aligns the pipeline with how npm pack behaves (it does not create --pack-destination automatically), preventing the first-tag release run from failing early.
Changes:
- Add an explicit
mkdir -p release-artifactbefore runningnpm pack --pack-destination ./release-artifact. - Run the pack step under
set -euo pipefail(consistent with other multi-linerunsteps in the workflow). - Document the reason for the directory creation directly above the pack step.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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.
The first real run of the release pipeline (tag
v2.0.1, run 31337884584) failed. Nothing was published —verifydied before uploading, sopublishwas skipped and never reached the approval gate.Cause
npm pack --pack-destination <dir>writes the tarball into<dir>but does not create it. The step assumed npm wouldmkdir -pon its way. Nothing before it createsrelease-artifact/either, so the very first invocation was always going to fail — the bug just couldn't surface until a tag was actually pushed.Reproduced locally both ways:
Fix
mkdir -p release-artifactbefore the pack, underset -euo pipefail.Verification
Simulated every
verifystep locally against this branch — version match, republish guard,npm ci, build, typecheck, lint, test, pack, and the publish job's exactly-one-tarball guard. All pass, and the pack now producesrelease-artifact/dfhack-remote-node-2.0.1.tgz.Once merged,
v2.0.1gets retagged onto the fix and re-pushed. The tag can be reused because nothing was ever published under it.