chore: add rivetkit-native cross-platform builds to pkg-pr-new#4600
chore: add rivetkit-native cross-platform builds to pkg-pr-new#4600NathanFlurry merged 53 commits intomainfrom
Conversation
PR Review: chore: add rivetkit-native cross-platform builds to pkg-pr-newThis is a significant infrastructure PR that unifies the build and publish pipeline into a single Issues
Each call to
When
Long cross-compilation jobs (Windows MinGW, darwin via osxcross) can hang silently. Without Minor Notes
SummaryThe publish unification architecture is clean and well-thought-out. The |
Preview packages published to npmInstall with: npm install rivetkit@pr-4600All packages published as Engine binary is shipped via Docker images: docker pull rivetdev/engine:slim-e13738f
docker pull rivetdev/engine:full-e13738fIndividual packagesnpm install rivetkit@pr-4600
npm install @rivetkit/react@pr-4600
npm install @rivetkit/rivetkit-native@pr-4600
npm install @rivetkit/sqlite-wasm@pr-4600
npm install @rivetkit/workflow-engine@pr-4600 |
2fa64c6 to
c8960f9
Compare
04c63da to
42de8ce
Compare
42de8ce to
04c63da
Compare
…ackages Adds @rivetkit/engine-cli meta package with per-platform optionalDependencies (linux-x64/arm64-musl, darwin-x64/arm64) and rewires rivetkit's engine-process to resolve the binary via @rivetkit/engine-cli getEnginePath() instead of downloading from releases.rivet.dev. This lets preview publishes ship a usable engine to npm under the pr-<num> dist-tag. - CI workflow places engine build artifacts into engine-cli/npm/<platform>/ - bump-versions injects optionalDependencies for both rivetkit-native and engine-cli meta packages - discover-packages scans both rivetkit-native/npm and engine-cli/npm
The rivet-engine binary is statically linked against musl, so the single musl build runs on both glibc and musl hosts. With libc:[musl] set on the platform package.json, npm was skipping the optionalDependency on glibc hosts (Debian/Ubuntu/etc), leaving them with no engine binary. Drop the libc constraint so every linux host installs the musl package, and simplify the resolver to map linux -> musl unconditionally.
…vetkit-native jobs The previous single build job with an 11-entry matrix mixed rivetkit-native and engine rows into one flat list. Splitting into two jobs gives each group its own matrix, its own UI expand/collapse in the Actions tab, and makes the distinction between native-addon builds and engine-binary builds explicit. The publish job now depends on both build jobs via needs: [build-rivetkit-native, build-engine].
Merge scripts/release/ and scripts/preview-publish/ into a single scripts/publish/ package with src/lib (shared modules), src/ci (workflow subcommands), and src/local (release cutter). Merge release.yaml and preview-publish.yaml into a single publish.yaml with a context job that resolves trigger/version/tag once and pins them as job outputs. Shared code path for PRs, main pushes, and release cuts: build matrix, per-arch Docker push, multi-arch manifest, R2 upload, npm publish. Release tail adds R2 copy to version prefix, Docker retag, git tag, and GitHub release. Windows engine binary is built only on release triggers via a matrix gate. Drops reuse_engine_version plumbing, the phase-based release orchestrator, and @rivetkit/sqlite-native platform package publishing (the sqlite-native Rust crate is now statically linked into @rivetkit/rivetkit-native via libsqlite3-sys bundled feature, so the standalone npm package is redundant). Preserves @rivetkit/devtools R2 upload under a release-only tail step because rivetkit client code still lazy-loads it from releases.rivet.dev.
- Replace CJS require('node:fs') with a top-level import in context.ts
(the file is ESM; require is not defined at runtime).
- Replace gh api -F body=@- (non-standard stdin file marker) with
-f body=<string> which execa template-interpolates directly.
Root postinstall runs lefthook install which requires .git, but .dockerignore excludes .git/ from the build context. Adding --ignore-scripts skips the postinstall entirely. lefthook is a dev git-hook manager and has no role inside the Docker image build.
Turbo's ^build graph pulls @rivetkit/rivetkit-native into build:engine -F @rivetkit/engine-frontend, which tries to run napi build inside the Docker context. cargo works in the rust:* image but the cache-mounted CARGO_HOME breaks rustup toolchain resolution. Add SKIP_NAPI_BUILD=1 honored by rivetkit-native/scripts/build.mjs and set it in the Dockerfile. The engine-frontend only consumes the TypeScript surface of rivetkit, not the runtime .node binary.
Turbo filters env vars by task-level allow-list; SKIP_NAPI_BUILD set in the Docker build was being stripped before reaching rivetkit-native build.mjs. Add it to the build task env list.
Preview Docker images push without the engine frontend UI. Release images include the full frontend. Sidesteps a pre-existing code bug in frontend/src/components/use-deployment-logs-stream.ts that imports a missing RivetSse value from a pkg.pr.new-hosted @rivet-gg/cloud.
pnpm --filter=publish exec runs in scripts/publish/, so relative args like 'engine-artifacts' and 'scripts/publish/static' resolved against the wrong base. Use $GITHUB_WORKSPACE-prefixed absolute paths for any --source/--scripts-dir args.
The previous base was read from rivetkit-native/package.json, which is just whatever version happens to be committed at the time — no semantic relationship to the PR being previewed. Hardcode 0.0.0 so previews are obviously not real releases and always sort below any X.Y.Z.
GITHUB_TOKEN needs workflows:write when pushing a tag that references a commit containing .github/workflows/ changes. Without it, GitHub rejects the push.
94419f9 to
0708022
Compare
a70240e to
d00c2b0
Compare
Merge activity
|

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context.
Type of change
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Checklist: