perf(ci): install dependencies once in a shared orbit-deps base image - #72
Conversation
The four service Dockerfiles each ran an identical bun install. Because web, realtime and mcp are multi-stage and ship only their bundle, that install layer is absent from the final image, so --cache-from cannot restore it and every fresh build host reinstalled three times over, in parallel, contending for the same cores. Build the install once in Dockerfile.deps and have every service image derive from it. migrate now shares that node_modules layer instead of duplicating it through a recursive chown, so its unique layers shrink to the copied source and it runs as the orbit user reading the root-owned modules.
…st it The build phase now builds Dockerfile.deps first and tags it locally, then the four service builds reference it through the DEPS_IMAGE build arg, so the shared node_modules is resolved from the local daemon with no reinstall. post_build pushes orbit-deps before the services, so their shared layer already exists in ECR and each service push uploads only its own small layers. pre_build also warms the orbit-deps cache image, which is what makes the install a cache hit across fresh on-demand hosts.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
pulkitxm has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 59 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (8)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
The container-images job built the service Dockerfiles directly, so after they
switched to FROM ${DEPS_IMAGE} it tried to pull orbit-deps:build from Docker Hub
and failed. Build the deps image first and pass it through, matching buildspec.
There was a problem hiding this comment.
pulkitxm has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
pulkitxm has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
1 participant
Install workspace dependencies once in a shared
orbit-depsbase image so the four service images stop reinstalling in parallel and instead share one node_modules layer.Prerequisite done: created the
orbit-depsECR repo (scanOnPush, AES256, MUTABLE), mirroring the others.Evidence (local, arm64):