feat: switch to esbuild-based build pipeline for faster builds#762
feat: switch to esbuild-based build pipeline for faster builds#762RomanNikitenko wants to merge 5 commits into
Conversation
|
Click here to review and test in web IDE: |
&message=Dev%20cluster%20(for%20maintainers)&logo=eclipseche&color=525C86&labelColor=FDB940)
|
Hi! I'm che-ai-assistant — I help with your pull requests. Available commands:
|
|
Pull Request images published ✨ Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-762-amd64 |
1 similar comment
|
Pull Request images published ✨ Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-762-amd64 |
Signed-off-by: Roman Nikitenko <rnikiten@redhat.com> Assisted-by: Cursor AI
Signed-off-by: Roman Nikitenko <rnikiten@redhat.com> Assisted-by: Cursor AI
4202161 to
6e2b121
Compare
There was a problem hiding this comment.
Pull request overview
Updates Che-Code’s build and static-asset delivery pipeline by integrating the new esbuild-based bundling flow into container builds and adding Che-specific support for serving pre-compressed static assets.
Changes:
- Adds Che-specific support to serve pre-compressed
.gzstatic assets when the client supportsgzip. - Updates container build Dockerfiles to run the new esbuild-based bundling pipeline and pre-compress static assets during image build.
- Refreshes Che server helper code/header to support the new static serving behavior.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
code/src/vs/server/node/webClientServer.ts |
Attempts to serve pre-compressed assets before falling back to the regular static file path. |
code/src/vs/server/node/che/webClientServer.ts |
Introduces tryServeCompressedFile helper and updates Che copyright header. |
build/dockerfiles/linux-musl.Dockerfile |
Switches Alpine build to the new esbuild-based bundling steps and adds gzip pre-compression of assets. |
build/dockerfiles/linux-libc-ubi9.Dockerfile |
Switches UBI9 build to the new esbuild-based bundling steps and adds gzip pre-compression of assets. |
build/dockerfiles/linux-libc-ubi8.Dockerfile |
Switches UBI8 build to the new esbuild-based bundling steps and adds gzip pre-compression of assets. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Pull Request images published ✨ Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-762-amd64 |
Ensure the Promise in tryServeCompressedFile settles when the client disconnects or a stream error occurs after headers are sent. Previously these scenarios left the Promise pending, which could hang the request handler. Signed-off-by: Roman Nikitenko <rnikiten@redhat.com> Assisted-by: Cursor AI
|
Pull Request images published ✨ Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-762-amd64 |
|
Warning Review limit reached
Next review available in: 52 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 (2)
📝 WalkthroughWalkthroughLinux libc and musl image builds now perform expanded compilation, TypeScript validation, Next.js bundling, CI web packaging, and pre-compression of selected static assets. The web server adds gzip eligibility checks and streams matching Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant DockerBuild
participant CheOutput
participant Client
participant serveFile
participant tryServeCompressedFile
DockerBuild->>CheOutput: Build web artifacts and gzip eligible assets
Client->>serveFile: Request static asset with Accept-Encoding
serveFile->>tryServeCompressedFile: Attempt compressed response
tryServeCompressedFile->>CheOutput: Read matching .gz file
CheOutput-->>tryServeCompressedFile: Return gzip stream
tryServeCompressedFile-->>Client: Send compressed asset with headers
Suggested reviewers: Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error)
✅ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@code/src/vs/server/node/che/webClientServer.ts`:
- Around line 48-50: Update the gzip negotiation logic around acceptEncoding so
it parses Accept-Encoding coding parameters and reads gzip’s effective quality
value. Return false when gzip is absent or explicitly assigned q=0, and only
enable gzip when its effective quality is greater than zero.
In `@code/src/vs/server/node/webClientServer.ts`:
- Around line 77-80: Update the response-header setup in the web client request
handler to add or append Vary: Accept-Encoding before the ETag/304 conditional,
ensuring both compressed and uncompressed responses advertise the encoding
variance. Pass responseHeaders when constructing the 304 response, while
preserving the existing conditional and file-serving behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b2049961-22e6-47d9-b360-bb7cedb11db7
📒 Files selected for processing (5)
build/dockerfiles/linux-libc-ubi8.Dockerfilebuild/dockerfiles/linux-libc-ubi9.Dockerfilebuild/dockerfiles/linux-musl.Dockerfilecode/src/vs/server/node/che/webClientServer.tscode/src/vs/server/node/webClientServer.ts
Skip gzip serving when the client explicitly refuses gzip by setting quality value to zero (e.g. Accept-Encoding: gzip;q=0). Signed-off-by: Roman Nikitenko <rnikiten@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Add Vary header before ETag/304 conditional so shared caches correctly distinguish compressed and uncompressed variants. Include responseHeaders in 304 response to propagate Vary to the client. Signed-off-by: Roman Nikitenko <rnikiten@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>
3832429 to
3bd8bde
Compare
|
Pull Request images published ✨ Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-762-amd64 |
rgrunber
left a comment
rgrunber
left a comment
There was a problem hiding this comment.
Build went from taking about ~20min locally (with balanced performance) to ~5min using the compile instructions.
Comparing the contents of code/.build/extensions shows no major differences.
What does this PR do?
gulp + custom TypeScript manglerto theesbuild-based pipeline.Build steps (per Dockerfile):
Before:
After:
What issues does this PR fix?
How to test this PR?
Testing any functionality is useful
I've tested basic functionality:
Does this PR contain changes that override default upstream Code-OSS behavior?
git rebasewere added to the .rebase folderSummary by CodeRabbit
Performance
Vary: Accept-Encodingand ensured 304 responses include the expected headers.Build Improvements