Skip to content

chore(engine): publish engine bases in ci#4649

Open
NathanFlurry wants to merge 2 commits into04-13-chore_lockfile_lefthookfrom
04-14-chore_engine_publish_engine_bases_in_ci
Open

chore(engine): publish engine bases in ci#4649
NathanFlurry wants to merge 2 commits into04-13-chore_lockfile_lefthookfrom
04-14-chore_engine_publish_engine_bases_in_ci

Conversation

@NathanFlurry
Copy link
Copy Markdown
Member

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

Copy link
Copy Markdown
Member Author

NathanFlurry commented Apr 14, 2026

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

@NathanFlurry NathanFlurry mentioned this pull request Apr 14, 2026
11 tasks
@github-actions
Copy link
Copy Markdown
Contributor

Preview packages published to npm

Install with:

npm install rivetkit@pr-4649

All packages published as 0.0.0-pr.4649.a36b881 with tag pr-4649.

Engine binary is shipped via @rivetkit/engine-cli on linux-x64-musl, linux-arm64-musl, darwin-x64, and darwin-arm64. Windows users should use the release installer or set RIVET_ENGINE_BINARY.

Docker images:

docker pull rivetdev/engine:slim-a36b881
docker pull rivetdev/engine:full-a36b881
Individual packages
npm install rivetkit@pr-4649
npm install @rivetkit/react@pr-4649
npm install @rivetkit/rivetkit-native@pr-4649
npm install @rivetkit/workflow-engine@pr-4649

@NathanFlurry NathanFlurry force-pushed the 04-13-chore_lockfile_lefthook branch from 494bf0e to f314a96 Compare April 14, 2026 23:43
@NathanFlurry NathanFlurry force-pushed the 04-14-chore_engine_publish_engine_bases_in_ci branch from 4170ac2 to eeabed8 Compare April 14, 2026 23:43
@claude
Copy link
Copy Markdown

claude bot commented Apr 14, 2026

PR Review: chore(engine): publish engine bases in CI

Overview

This PR introduces a pattern where engine-specific Docker base images (engine-builder, engine-runtime-full, engine-runtime-slim) are published to GHCR on every commit SHA, replacing inline setup steps in the main docker/engine/Dockerfile. It also removes the deprecated @rivetkit/sqlite-wasm package from build/publish pipelines.

The approach is sound -- pre-baking slow layers (Rust toolchain, FDB client, Node.js) into versioned base images speeds up the main Docker build significantly.


Issues

ENGINE_BASE_TAG=latest default is fragile

The latest tag likely does not exist on GHCR since all published tags are commit SHAs. A local docker build without --build-arg ENGINE_BASE_TAG=<sha> will fail with a pull error. Consider adding a comment in the Dockerfile header documenting the required invocation, or defaulting to a known pinned SHA.

Dev container base images used for production runtime

engine-runtime-full.Dockerfile and engine-builder.Dockerfile use mcr.microsoft.com/devcontainers/base:debian and mcr.microsoft.com/devcontainers/rust:1-1-bookworm as their bases. Dev container images ship tooling intended for developer environments and are significantly larger than debian:bookworm-slim / rust:1.91.0-slim-bookworm equivalents. This will bloat the final runtime images. Recommend switching to minimal upstream images.

SHA format assumption between CI and the build script

The CI passes ENGINE_BASE_TAG=${{ needs.context.outputs.sha }} but build-push.sh uses git rev-parse --short HEAD. If context.outputs.sha is a full 40-char SHA, the tags pushed by CI and the tag expected by the Dockerfile build arg will not match. Verify that context.outputs.sha is the short (7-char) form.

engine-base-images job does not use the updated docker-setup action

The PR adds GHCR login to docker-setup/action.yaml but the new engine-base-images job inlines its own GHCR login step instead of calling docker-setup. This means future improvements or fixes to the shared action will not apply to engine-base-images, and the two paths can drift.


Minor Notes

  • build_one() for multiarch only loads linux/amd64 -- the local (no --push) path builds amd64 only. This is a known limitation of docker buildx --load with multi-platform targets, but a comment in the script would help avoid confusion.
  • No integrity check on FDB library download -- all three Dockerfiles curl the FDB .so from GitHub releases without a checksum verification step. Adding sha256sum verification would improve supply-chain integrity.
  • GHCR tag accumulation -- a new image tag is published per commit SHA. Consider a GHCR retention/cleanup policy or a periodic workflow to prune old tags.
  • @rivetkit/sqlite-wasm removal -- consistently applied across the CI workflow, packages.ts, and cut-release.ts. Looks correct.
  • Unused local dockerfile in push_one() -- declared at the top of the function but only referenced in the multiarch branch. Minor nit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant