perf(ci): add fast WASM validation for pull requests

[ttw225]

Summary

This draft proposes a faster validation path for WASM pull requests while
retaining fully optimized builds and size enforcement on production paths.

It is intentionally opened as a draft because this changes when optimized-size
regressions are detected. I would like maintainer feedback on that trade-off
before treating the implementation as ready to merge.

Part of #2518. This does not close the issue because the main-owned cache work
is tracked separately.

Context

Recent Build WASM + TypeScript SDK runs took approximately:

Scenario	Cargo compile	wasm-opt	wasm-pack total
Warm cache	1:09	~15:13	16:45
Cold cache	10:16	~18:25	29:04

The Binaryen wasm-opt pass therefore contributes approximately 15–18 minutes
to every pull request, independently of the Cargo cache state.

• Warm example: https://github.com/Canner/WrenAI/actions/runs/29254751463
• Cold example: https://github.com/Canner/WrenAI/actions/runs/29251947757

Proposed behavior

Path	Build mode	Size validation	Timeout
Pull request	release build with --no-opt	skipped	20 min
Push to main	fully optimized release build	15 MiB gzip	40 min
Stable publish	fully optimized release build	before npm publish	40 min
RC publish	fully optimized release build	before npm publish	40 min

The timeout values are upper bounds for detecting stuck jobs; they are not
expected runtimes. The first cold-equivalent PR run completed in 11:18, including a 10:47
wasm-pack --no-opt phase. This meets the ≤12-minute cold target. A true warm
run has not yet been observed, so the 2–3 minute warm estimate remains
unconfirmed.

What changed

• Use wasm-pack build --target web --release --no-opt only for pull requests.
• Keep the existing fully optimized build on main.
• Skip the production size gate for the non-optimized PR artifact.
• Add one tested npm run check:size implementation shared by:
  • the optimized main build;
  • stable npm publishing;
  • RC npm publishing.
• Preserve the existing 15 MiB gzip limit and historical system-gzip
  measurement.
• Block npm publish when an optimized artifact exceeds the limit.
• Report the selected build mode, Cargo exact-cache hit, and wasm-pack
  duration in the Actions job summary.
• Add 20-minute and 40-minute job timeout ceilings.
• Keep cache ownership, save/restore policy, and cache-key redesign out of this
  PR.

The 15 MiB limit is not newly introduced here. The current optimized artifact
is approximately 13.8 MiB gzip; this PR centralizes the existing check and also
applies it directly to both publish paths.

Trade-off and feedback requested

The main trade-off is that an optimized-size regression would be detected on
the first main build after merge rather than during the pull request.

The current main ruleset does not require status checks, so the optimized PR
size result is advisory today rather than an enforced merge gate. Nevertheless,
pre-merge visibility may still be valuable to maintainers, and I do not want to
assume that shorter PR feedback is necessarily more important than running the
full optimizer on every PR.

I would especially appreciate feedback on:

1. Is moving optimized-size detection from PR time to main acceptable?
2. Would maintainers prefer to keep the full 17–29 minute optimized PR build,
   even though it is not currently an enforced merge gate?
3. Are the 20-minute PR and 40-minute optimized-build timeout ceilings useful,
   or would different values/no timeout be preferable?
4. Should stable and RC publish workflows directly enforce the existing size
   limit before npm publish, as proposed here?

If pre-merge optimized validation is preferred, I am happy to retain the
current full PR build. Another future option would be enforcing the optimized
gate through a merge queue using merge_group.

CI measurement

Two PR runs have completed successfully:

Run	Cache observation	wasm-pack	Job total
Initial PR run	exact-key restore, but compiler-stale/full rebuild	10:47	11:18
After rebasing onto main	same exact key and another near-full rebuild	10:51	11:26

Runs:

• https://github.com/Canner/WrenAI/actions/runs/29556999300/job/87811153626
• https://github.com/Canner/WrenAI/actions/runs/29558380493/job/87815362921

In both runs, the PR fast path, typecheck, and all 43 tests passed. The optimized
build and production size gate were correctly skipped.

Although actions/cache reported an exact-key restore, neither run was a usable
warm build. Both restored the same main cache, which was created on July 15,
while rust-toolchain@stable resolved to Rust 1.97.1 after the July 16 stable
update. Because the current key does not include compiler identity, Cargo
invalidated the restored fingerprints and performed a near-full rebuild.

The second run naturally reproduces this behavior after rebasing onto main;
the unchanged exact key was restored again and could not be refreshed.

These runs should therefore be treated as cold-equivalent rather than warm:

• previous cold wasm-pack: 29:04
• PR fast-path wasm-pack: 10:47–10:51
• saving: 18:13–18:17, approximately 63%
• total PR job: 11:18–11:26, within the ≤12-minute cold target in both runs

A true warm-path measurement is still pending. I will not force one by deleting
or manipulating caches. The repeated stale exact-hit behavior also provides
concrete evidence for the compiler-aware cache-key work tracked in the
follow-up cache PR.

Validation

Completed locally:

• just test: 43/43 passed
• npm test: 43/43 passed
• npm run typecheck: passed
• actionlint for all three modified workflows: passed
• git diff --check: passed
• Real optimized artifact:
  • shared checker: 14,547,440 gzip bytes / 13.8 MiB
  • direct gzip -c <file> | wc -c: 14,547,440 bytes

After opening the draft, I will record the actual warm/cold PR timings and
confirm that the post-merge optimized path retains the existing size result.

Summary by CodeRabbit

• New Features
  • Added a production WASM size gate using npm run check:size, with configurable gzip-size limits and clearer reporting.
  • Publishing workflows now run the size check before integration tests and npm publish.
• Bug Fixes
  • Improved CI reliability with explicit job timeouts and clearer build-time metrics.
• Tests
  • Expanded WASM SDK tests to include size-gate coverage (including boundary and failure scenarios).
  • Pull-request CI uses faster unoptimized builds, while size checks apply to optimized artifacts only.

[coderabbitai]

Walkthrough

Changes

WASM size-gated validation

Layer / File(s)	Summary
WASM size gate and coverage core/wren-core-wasm/scripts/check-size.mjs, core/wren-core-wasm/sdk/tests/check-size.test.mjs	Adds configurable gzip-size validation for WASM artifacts and tests success, boundary, configuration, artifact, and gzip-command failure cases.
SDK test command wiring core/wren-core-wasm/package.json, core/wren-core-wasm/justfile	Adds the check:size script and includes size-gate tests in npm test and the test recipe.
Event-specific WASM CI builds .github/workflows/wasm-ci.yml	Uses separate PR and non-PR build modes, records build metrics, adjusts timeouts, and runs size checks for optimized artifacts.
Publishing workflow gates .github/workflows/publish-wren-core-wasm*.yml	Adds 40-minute job limits and runs the WASM size check before integration tests and npm publication.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GitHubActions
  participant wasm-pack
  participant npmCheckSize
  participant npmPublish
  GitHubActions->>wasm-pack: Build PR or optimized non-PR WASM artifact
  wasm-pack-->>GitHubActions: Produce dist WASM artifact
  GitHubActions->>npmCheckSize: Run npm run check:size
  npmCheckSize-->>GitHubActions: Return size validation result
  GitHubActions->>npmPublish: Publish only after validation and tests pass

Loading

Possibly related issues

• Improve WASM SDK CI performance and cache reliability #2518 — Covers the planned fast pull-request builds, optimized WASM size checks, and publish-path enforcement.

Possibly related PRs

• Canner/WrenAI#2216 — Updates the reusable WASM npm publishing workflow with size checks and job timeouts.
• Canner/WrenAI#2240 — Updates the RC publishing workflow with matching size-check and timeout steps.

Suggested reviewers: goldmedal

Poem

I’m a rabbit guarding bytes in a burrow so bright,
Gzip hops through the gate and measures just right.
Fast builds race while optimized artifacts gleam,
Tests thump their paws through the publishing stream.
Only sized-up WASM reaches the dream!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 42.86% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the main change: a faster WASM validation path for pull requests.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}