fix(publish): build the image for arm64 too - #533
Conversation
E2B Embed pins this image and runs on arm64 hosts. The push path builds a linux/amd64,linux/arm64 manifest list with QEMU for the arm64 half; the dry run keeps a single platform because --load can only hold one.
svalleru
changed the title
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.
Additional findings (outside the current diff — GitHub can't attach inline comments there):
-
🟡
tests/unit/publish-workflow.test.ts— nit: the file-level docstring still says these tests guard "the single architecture", but the assertions below now check for a two-platform (linux/amd64,linux/arm64) build, so the comment misdescribes what the test actually enforces. Fix: update the docstring to mention both platforms so it stays accurate for maintainers reading the test file.Extended reasoning...
The docstring at tests/unit/publish-workflow.test.ts:5-9 was written when publish.yml only built linux/amd64 and says the tests guard "the registry it pushes to, the single architecture, and the attestation switches". This PR changes the assertion at line 36 to require 'platforms=linux/amd64,linux/arm64' and adds a check for the QEMU action, but leaves the docstring text unchanged. A maintainer reading only the docstring (not the assertions) would wrongly believe the published image is still single-arch, which is stale and misleading documentation introduced by this diff.
Verification: nit: Stale comment. The file-level docstring at tests/unit/publish-workflow.test.ts:5-9 states the assertions "guard the flags it cannot go without: the registry it pushes to, the single architecture, and the attestation switches". The diff changed the assertion at line 36 from '--platform linux/amd64' to 'platforms=linux/amd64,linux/arm64' and added 'docker/setup-qemu-action@' at line 37, so…
The file docstring still described a single-architecture build after the assertions moved to linux/amd64,linux/arm64 (review nit on #533).
🤖 I have created a release *beep* *boop* --- ## [0.2.1](v0.2.0...v0.2.1) (2026-09-16) ### Bug Fixes * **publish:** build the image for arm64 too ([#533](#533)) ([8ca65cd](8ca65cd)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: e2b-generated-code-auto-fixer[bot] <257264331+e2b-generated-code-auto-fixer[bot]@users.noreply.github.com>
2 participants
Summary
E2B Embed pins this image and supports arm64 hosts, and the published image is
linux/amd64only. The publish workflow now sets up QEMU and builds alinux/amd64,linux/arm64manifest list on the push path. The dry run keeps a single platform, because--loadcan only hold one image in the local daemon. The arm64 half runs its Bun install and Next build under emulation on purpose: cross-building on amd64 would ship amd64-only native modules (sharp) inside the standalone output. The job timeout moves from 30 to 90 minutes to allow for it. README names both platforms. Sponsor: @svalleru.Verification
vitest run tests/unit/publish-workflow.test.tspasses (asserts the platform list and the QEMU action; every action stays SHA-pinned with a version comment).The title is a
fixon purpose: a release whose image cannot be pulled on arm64 is a defect in the released artifact, so merging this opens the 0.2.1 release PR and that tag publishes the first multi-arch image.Risk & rollout
Publish takes longer (emulated arm64 build). Existing tags are unaffected; Embed re-pins to the first multi-arch release in its own PR.