ci(release): fail closed when npm pack reports no tarball - #69
Conversation
The e2e-smoke gate could pass without ever exercising the tarball it exists to
exercise:
TARBALL="$(npm pack --silent | tail -n1)"
TARBALL="$PWD/$TARBALL"
npm install --no-save "$TARBALL"
Some npm versions suppress the emitted filename on stdout under --silent. When
that happens TARBALL is empty, `$PWD/` is a DIRECTORY, and `npm install`
happily installs the workspace directory instead. Every assertion after it
then passes -- against the working tree, not against the packed artifact. The
gate goes green having proved nothing about what would actually ship.
That is the same fail-open shape as a swallowed error: the check does not
fail, it stops being a check.
Replaced with `npm pack --json`, whose filename field is not
verbosity-dependent, plus two assertions -- the value ends in .tgz, and the
file exists on disk.
Verified both directions rather than just the happy path:
happy path PACK OK -> wave-av-adk-1.0.2.tgz exit 0
empty TARBALL ::error::npm pack --json reported '', not
a .tgz filename exit 1
A guard that has never been observed rejecting anything is not yet a guard.
Credit where it is due: a peer found this in the mcp-server copy of the same
workflow (bb1bf17) and fixed it there. I had written the --silent version and
copied it across repos, so this propagates their fix to the two that still
carry it.
|
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_5f32e8f7-e5c9-4c18-befa-6334adedb6cd) |
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 25 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Comment |
|
@coderabbitai review Context for the review: this propagates a fail-open fix a peer found in the mcp-server copy of this same workflow (bb1bf17). The e2e-smoke used |
|
✅ Action performedReview finished.
|
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_50390b38-143e-47b7-b4e0-f6b56d871133) |
|
@coderabbitai review (Re-requesting against the new head — the branch was just updated from main, which orphaned the previous request.) |
|
✅ Action performedReview finished.
|
|
@coderabbitai full review |
✅ Action performedFull review finished. Your included review limit is currently reached under our Fair Usage Limits Policy. Your recent PR review activity is in the 95th percentile or higher among CodeRabbit users, so adaptive limits apply. This review may still proceed through usage-based billing if eligible. Your next included review will be available in 39 minutes. |
|
@coderabbitai full review |
✅ Action performedFull review finished. Your included review limit is currently reached under our Fair Usage Limits Policy. Your recent PR review activity is in the 95th percentile or higher among CodeRabbit users, so adaptive limits apply. This review may still proceed through usage-based billing if eligible. Your next included review will be available in 54 minutes. |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_c230e756-cfd9-45e0-81a8-93102b3efe18) |
ApprovabilityVerdict: Approved 37094b3 This CI workflow change adds defensive validation to You can customize Macroscope's approvability policy. Learn more. |
The e2e-smoke gate could pass without ever exercising the tarball it exists to
exercise:
TARBALL="$(npm pack --silent | tail -n1)"
TARBALL="$PWD/$TARBALL"
npm install --no-save "$TARBALL"
Some npm versions suppress the emitted filename on stdout under --silent. When
that happens TARBALL is empty,
$PWD/is a DIRECTORY, andnpm installhappily installs the workspace directory instead. Every assertion after it
then passes -- against the working tree, not against the packed artifact. The
gate goes green having proved nothing about what would actually ship.
That is the same fail-open shape as a swallowed error: the check does not
fail, it stops being a check.
Replaced with
npm pack --json, whose filename field is notverbosity-dependent, plus two assertions -- the value ends in .tgz, and the
file exists on disk.
Verified both directions rather than just the happy path:
happy path PACK OK -> wave-av-adk-1.0.2.tgz exit 0
empty TARBALL ::error::npm pack --json reported '', not
a .tgz filename exit 1
A guard that has never been observed rejecting anything is not yet a guard.
Credit where it is due: a peer found this in the mcp-server copy of the same
workflow (bb1bf17) and fixed it there. I had written the --silent version and
copied it across repos, so this propagates their fix to the two that still
carry it.
Note
Low Risk
CI-only change to release workflow tarball detection; no runtime or publish logic changes beyond making the existing smoke gate fail closed.
Overview
The release e2e-smoke step no longer derives the pack filename from
npm pack --silent | tail -n1, which could leaveTARBALLempty on some npm versions and letnpm installsucceed against the workspace directory instead of a.tgz.It now uses
npm pack --json, parses thefilenamefield with a small Node one-liner, and fails the job if the name does not end in.tgzor the file is missing on disk—so the smoke test always installs the real packed artifact before CJS/ESM/bin checks run.Reviewed by Cursor Bugbot for commit 37094b3. Configure here.
Summary by cubic
Makes the release e2e-smoke step fail closed and always test the real packed tarball. Uses
npm pack --jsonwith guards so we never install the workspace directory by accident.filenamefrom JSON via a Node one-liner..tgzsuffix and verify file exists; otherwise exit 1.Written for commit 37094b3. Summary will update on new commits.
Note
Fail the release e2e-smoke step when
npm packdoes not produce a valid tarballnpm pack --silent | tail -n1withnpm pack --jsonpiped through a Node script that extracts the firstfilenamefield, making tarball capture reliable across npm versions..tgzand that the file exists on disk, emitting GitHub Actions error annotations and exiting non-zero on failure.npm pack --jsonoutput differs from expectations will now fail the job explicitly rather than silently falling back to a directory install.Macroscope summarized 37094b3.