Repository navigation
fix(aws-lambda): keep the arm64 image staging script out of the published package - #6118
Conversation
…shed package stage-arm64-image.ts is run from a checkout by the image workflow and the publish job, and nothing in dist or the CLI imports it. With the release's prebuilt/ files added, aws-lambda measured 73484 bytes packed and 267013 unpacked in the publish job, over its budgets of 73369 and 266805, so v0.8.187 did not publish.
5af7b40 to
24ad35b
Compare
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verdict: APPROVE · 0 blocker · 0 important · 0 nits · head 24ad35b4
Scope
stage-arm64-image.ts is only ever run from a checkout (publish.yml:194, lambda-arm64-image.yml:93). Nothing in src, dist or the README points package users to it, so leaving it out of the tarball is safe. The new Build step uses the same pin-handler-zip.ts (plus --video-image) that publish runs before verify:packed-manifests. bun run build doesn't produce handler.zip, so the stand-in assets stay in place, and no later Build step reads prebuilt/. At this head, the Build job's pin and verify:packed-manifests steps both passed. CodeQL, Windows and the Lambda arm64 image runs were still in progress.
Edit accuracy: accurate 271 (base branch 271), smooth 159 of thoseThe gate passes. Quarantined, measured but not gated (0) |
24ad35b to
cae7bfe
Compare
…ublish job The publish job adds prebuilt/handler-zip.json and prebuilt/video-image.json before verify:packed-manifests; the PR check did not, so a package could pass on the PR and fail at publish. The verifier now runs the same pin script on sparse stand-ins of release size when no pins exist, and removes them afterwards. It lives in the verifier, not a Build step, so the edit-accuracy input closure stays unchanged.
cae7bfe to
6fdbc80
Compare
There was a problem hiding this comment.
Verdict: APPROVE · 0 blocker · 0 important · 0 nits — 0 resolved, 0 open, 0 new · 24ad35b4 → 6fdbc802
The stand-in pins moved into verify-packed-manifests.mjs. Publish is unaffected: its real handler-zip.json makes the new step a no-op. A developer's built zip, image, hashes and pins are moved aside and restored on both the success and error paths. The template the pin script writes is the same one build.mjs writes. The Build job's verify:packed-manifests passed at this head.
The v0.8.187 publish job stopped in
verify:packed-manifests: with the release'sprebuilt/files added,@hyperframes/aws-lambdameasured 73484 bytes packed and 267013 unpacked, over its budgets of 73369 and 266805.scripts/stage-arm64-image.tsships in the package but only runs from a checkout (the image workflow and the publish job). Nothing indistor the CLI imports it, so this keeps it out of the tarball, the same aspin-handler-zip.ts. The budgets stay as they are.Measured on a built tree with
prebuilt/generated by the real template writer and stand-in pin manifests,npm pack --dry-run: 73022 packed and 267570 unpacked before, 71425 and 262974 after (-1597 B and -4596 B). The publish job reads about 460 B higher packed and 560 B lower unpacked than these local numbers, so it should land near 71885 and 262417.The PR-time check could not catch this: the publish job adds the two release pins (
prebuilt/handler-zip.json,prebuilt/video-image.json) beforeverify:packed-manifests, and the Build job did not. The verifier now runs the same pin script on sparse stand-ins of release size when no pins exist (and removes them afterwards), so both runs pack the same file list.Proof, on a full build with the stand-in pins: with main's file list the check fails with aws-lambda unpacked 267013 (the exact figure the publish job reported) over 266805, packed 73405 over 73369; with the exclusion it passes (
Verified 14 packages are within their size budgets).No visible change
Package file list and one CI step only.