feat(cli): build deployment images on prebuilt base images - #4602
Conversation
Every project's build ran apt-get against the live Debian archive, making the package layer a per-project near-duplicate that worker nodes each cached separately and adding an installation step to every cold build. The generated Containerfile now starts from the published triggerdotdev/node and triggerdotdev/bun images (and their -build toolchain variants for the build stage), which ship the default packages prebuilt: no apt runs for uncustomized projects, and the base layers are identical across all projects by construction. User instructions and packages apply on top in both stages, with user packages in their own sorted install that allows downgrading pinned defaults.
apt-get install refuses to run on dpkg state an instruction left broken (the dpkg -i pattern audioWaveform uses), so repair ahead of the user package install whenever instructions preceded it. Customized projects build FROM base with the toolchain installed on top so instructions run exactly once instead of twice in independent stages, keeping external downloads single-shot; uncustomized projects keep the prebuilt toolchain image and zero apt. A test now pins DEFAULT_PACKAGES to the published images' package list.
…ten repairs Package-only projects have no instructions to run twice, so they keep the prebuilt toolchain image and repeat only the small package install instead of fetching the toolchain from the live archive per build. The repair steps use --no-install-recommends like every other apt call, the regression test asserts the composed repair-then-install RUN (the index comparison was vacuously true when the repair was missing), and the package-list sync test resolves paths from the test file and also pins the toolchain list.
🦋 Changeset detectedLatest commit: 044d3d0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 27 packages
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 |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📜 Recent review details⏰ Context from checks skipped due to timeout. (1)
WalkthroughContainer image generation now uses pinned Trigger.dev Node and Bun runtime and build images. Default packages are preinstalled in those images, while custom 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
@trigger.dev/build
trigger.dev
@trigger.dev/core
@trigger.dev/python
@trigger.dev/react-hooks
@trigger.dev/redis-worker
@trigger.dev/rsc
@trigger.dev/schema-to-json
@trigger.dev/sdk
commit: |
Every publish now also pushes an immutable per-publish tag alongside the mutable one, named after the snapshot date and commit (e.g. `22-bookworm-20260812-45444a7`), so previously published digests stay tag-referenced after republishes. Shipped CLI releases pin those digests, so they must remain resolvable indefinitely. Merging triggers a republish; the fresh tag-protected digests will then be pinned by #4602 before it merges.
The publish now pushes an immutable per-publish tag, so these digests stay tag-referenced permanently regardless of future republishes.
The generated deploy Containerfile now starts from the prebuilt base images published by base-images/ (
triggerdotdev/nodeandtriggerdotdev/bunon DockerHub, pinned by digest) instead of installing system packages during every project's build. Uncustomized projects run no apt at all and their base layers are identical across every project, so worker nodes cache one copy fleet-wide. The build stage uses the -build toolchain variant for uncustomized and package-only projects; projects with image instructions build FROM base so instructions and their downloads run exactly once.Notes