feat(cli): replace the cartesi-machine spawn with @cartesi/machine - #509
feat(cli): replace the cartesi-machine spawn with @cartesi/machine#509tuler wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: eeee1e5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Coverage Report
📁 File Coverage (20 files)
|
Note on the
|
| image: TEST_SDK, | ||
| cwd: machineDir, | ||
| }); | ||
| it("should return the hash of a stored machine", async () => { |
There was a problem hiding this comment.
I opened a PR regarding that
Migrated to
|
1abc6bb to
d02ec21
Compare
d02ec21 to
be559bf
Compare
tuler
changed the title
Configure, boot, store and hash the Cartesi machine through the @cartesi/machine N-API bindings, instead of spawning cartesi-machine and cartesi-machine-stored-hash (falling back to running them inside the SDK docker image). machine.ts now translates a cartesi.toml Config into an emulator MachineConfig directly, mirroring what the cartesi-machine CLI does with its command line: the boot args it appends to, the init script (splash, flash drive mounts and chowns, environment exports, WORKDIR and USER), the flash drives with root first so it lands on pmem0, and the virtio console setup for an interactive shell. buildMachineConfig is a pure function, covered by unit tests. With no SDK image to take the kernel from, images.ts downloads the pinned cartesi/machine-linux-image release on first use, verifies its checksum and caches it under XDG_CACHE_HOME. CARTESI_IMAGES_PATH and machine.ram_image still win. The emulator moves from 0.20 to 0.21, so machine hashes change. The standalone binaries are gone: a bun single file executable has no node_modules, and the addon resolves its platform .node at runtime, so it cannot be embedded. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UTEd5g3mF849BATTstssR3
be559bf to
eeee1e5
Compare
3 participants
Contributes to #72.
That issue asks for the external programs the CLI drives to stop being spawned binaries, and notes that "instead of spawning binaries another possibility is to build NodeJS bindings to native code components". This PR takes that route for the emulator.
cartesi-machineexeca, falling back todocker runin the SDK image@cartesi/machinecartesi-machine-stored-hashexeca, falling back todocker runin the SDK image@cartesi/machinexgenext2fsgets the same treatment in #517, stacked on this branch.mksquashfs,cartesi-rollups-cliandcartesi-rollups-nodeare untouched by either, so the remaining work on #72 is the Node Unit's binaries.Note
The branch name still says
xgenext2fs-cartesi-machine— it carried both changes before the split, and GitHub does not allow repointing a PR's head branch. Only the machine commit is here now.What changed
src/machine.ts— the substantial part. The CLI used to handcartesi-machinea command line and let it assemble the machine configuration. It now does that translation itself, transcribed fromcartesi-machine.luav0.21.0:dtb.bootargsfrom the emulator, withmachine.boot_argsappendeddtb.init: the splash, thendev=$(flashdrive <label>)+ mount + chown per non-root drive, thenexport K="V",WORKDIR,USER— in the order the old argv producedrootfirst, so it lands on/dev/pmem0regardless of the order drives appear incartesi.tomlconsole=hvc1andiunrep=1forcartesi shellbuildMachineConfigis a pure function so this is unit-testable without running a machine;src/exec/cartesi-machine.tsholds the run loop (automatic yields acknowledged, console I/O resumed, guest exit code read fromhtif_tohost_data).src/images.ts(new) — with no SDK image to takelinux.binfrom, the defaultram_imageis fetched from the pinnedcartesi/machine-linux-imagev0.21.0 release on first use, verified against its SHA-256 and cached under$XDG_CACHE_HOME/cartesi/images. ACARTESI_IMAGES_PATHdirectory holding the image is used when set, andmachine.ram_imagestill wins over both.Breaking
@cartesi/machinelinks against emulator 0.21, the SDK image pins 0.20. Applications need redeploying.--append-bootargs="<arg>"with no shell in between, so the quotes ended up in the kernel command line. Building the configuration directly, reproducing that would have meant reproducing a bug.node_modules, and the addon resolves its platform.nodeat runtime — a host-native--compilefails too, so cross-compiling four targets was never going to work. The compile step inbuild.tsand the upload step inrelease.yamlare removed here. The homebrew formula incartesi/homebrew-tapneeds to install from npm rather than the release tarball. Happy to revert this bit and solve distribution differently if you'd rather keep the binaries.Testing
tests/unit/machine.test.tsis new and covers the configuration translation (mount points, drive ordering, environment precedence, workdir/user, interactive mode,parseMemorySize).cartesi-machinemoved fromtests/integration/totests/unit/, since it no longer needs Docker.cartesi-machine-stored-hash.test.tsasserted a literal hash that the emulator bump invalidates. It now asserts shape and stability — worth pinning the real value once CI produces it.Not verified locally: a successful rollup application boot, which needs Docker with riscv64. The integration tests cover that path.