Uh oh!
There was an error while loading. Please reload this page.
fix(ci): give the web build a heap ceiling and repair stale typecheck filters - #150
Merged
Conversation
… filters The `apps/pythinker-web` vite build needs just over 2 GB of old space since the workspace file editor pulled Monaco into the production graph. macOS runners default to a ~2053 MB ceiling, so three jobs died with exit 134: Desktop Release's `mac` and Release's `darwin-x64` / `darwin-arm64` native bundles. Linux and Windows runners default higher and stayed green, which is why CI never caught it. Setting the ceiling in the package's own build script covers every consumer — CI, Nix, both release workflows and local builds — and stays portable, unlike a `NODE_OPTIONS=` prefix, which cmd.exe rejects on the Windows desktop job. Measured floor: 2048 MB fails, 2560 MB passes; the build peaks near 2.2 GB. Separately, `pnpm --filter <name>` exits 0 when nothing matches, so three typecheck gates had gone quietly dead: `@pymodel/dashboard-server` and `@pymodel/dashboard-web` matched nothing after the vis rename, and `pythinker-code` matched the CLI directory instead of the VS Code extension (`pythinker`), leaving the extension unchecked. Resolving each filter before running it turns a stale name back into a failure.
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe PR increases the web build memory limit, updates the bundle manifest hash, replaces fixed CI typecheck steps with a fail-fast workspace loop, and strengthens release CDN verification gates. ChangesBuild and Release Validation
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk:⚪ Minimal · up to The PR adjusts build memory limits and release/typecheck workflow behavior; no actionable merge-blocking risk remains based on the supplied evidence. Sequence Diagram(s)sequenceDiagram
participant release
participant publish_native_assets
participant redeploy_cdn
participant verify_cdn_release
release->>publish_native_assets: publish native assets when applicable
publish_native_assets->>redeploy_cdn: report publication status
release->>redeploy_cdn: report release status
redeploy_cdn->>verify_cdn_release: complete or skip CDN redeployment
release->>verify_cdn_release: report release status
verify_cdn_release->>verify_cdn_release: evaluate release and commit conditions
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Comment |
commit: |
`publish-native-assets` correctly refuses to publish a partial native set, but a job whose dependency failed reports `skipped`, not `failure`. `redeploy-cdn` only checked for `failure`, so it deployed 1.0.0 to the CDN while the GitHub release held zero assets — every native installer would have been pointed at a release that has none. It now requires that job to have succeeded whenever the release has native artifacts at all, leaving the CDN on the last installable version otherwise. `verify-cdn-release` had no `always()`, so the same upstream skip propagated through the graph and silently disabled the one gate that exists to catch a half-shipped release. It now runs on its own merits and reports the stale CDN instead of vanishing with it.
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related Issue
No filed issue. Three release jobs failed on
mainatae4211f1f, and the failure then walked past two gates that should have caught it.Problem
1.
apps/pythinker-weboutgrew Node's default heap on macOS runners. The workspace file editor pulled Monaco into the production module graph (1 source file importing it before #145, 4 after), and the vite build now needs a little over 2 GB of old space. macOS runners default to a ~2053 MB ceiling, so three jobs died withFATAL ERROR: ... JavaScript heap out of memoryand exit 134:mac— "Build workspace"darwin-x64darwin-arm64Linux and Windows runners default higher and stayed green, so
CIandNix Buildnever saw it.2. A half-shipped release passed as a good one.
publish-native-assetsrefused to publish a partial native set, exactly as designed. But a job whose dependency failed reportsskipped, notfailure, andredeploy-cdnonly checked forfailure— so it deployed 1.0.0 to the CDN while the GitHub release@pymodel/pythinker-code@1.0.0held zero assets. Every native installer would have been sent to a release that has none.verify-cdn-releasehad noalways(), so the same skip propagated through the graph and silently disabled the one gate that exists to catch this. Both went quiet in precisely the run that needed them.3. Three typecheck gates in CI had gone quietly dead.
pnpm --filter <name>exits 0 when the filter matches nothing, so a rename turns a gate into a no-op with nothing red to show for it:@pymodel/dashboard-serverand@pymodel/dashboard-webmatched nothing after the packages became@pymodel/vis-server/@pymodel/vis-web.pythinker-codematched the CLI directory (apps/pythinker-code), not the VS Code extension, whose package name ispythinker. The extension was never typechecked in CI, and the CLI was already covered by the tsgo step above it.What changed
The heap ceiling lives in
apps/pythinker-web's ownbuildscript. That is the one point every consumer shares — CI, Nix, both release workflows, and local builds — and it stays portable: aNODE_OPTIONS=prefix would break the Windows desktop job, which runs the same script undercmd.exe. Measured on this repo rather than guessed: 2048 MB fails, 2560 MB passes, and the build peaks near 2.2 GB. 4096 leaves headroom without reserving anything, since V8 only grows to what it needs. Rebuilding the committed bundle produced a byte-identicaldist-web— only the input fingerprint moved, which confirms the change is behaviour-neutral.redeploy-cdnnow requirespublish-native-assetsto have succeeded whenever the release has native artifacts at all, so a release with no assets leaves the CDN on the last installable version instead of advertising one nobody can install.verify-cdn-releasenow runs on its own merits and reports a stale CDN rather than disappearing with it.The CI typecheck steps become one loop that resolves each filter to a real workspace package before running it, so a stale name fails instead of passing silently. All five targets pass locally, including the VS Code extension, which this turns on for the first time.
Checklist
/approve).gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.[skip changeset] — build and CI infrastructure only; the shipped bundle is byte-identical.
Summary by CodeRabbit
Bug Fixes
Chores