fix: Build web dashboard assets before Go compilation#107
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes the “blank white page” in waza serve by ensuring the Vite-built dashboard bundles in web/dist/assets/ are generated before the Go binary embeds web/dist/.
Changes:
- Add a dedicated frontend build step (
npm ci && npm run build) to Makefile,build.sh, and the Docker build (multi-stage). - Update the committed
web/dist/index.htmlto reference the newly generated Vite-hashed bundles. - Add webserver tests to assert embedded bundles exist and that
index.htmlreferences assets that are actually served as JS/CSS (not the SPA HTML fallback).
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| web/dist/index.html | Updates bundle hash references produced by Vite build output. |
| internal/webserver/server_test.go | Adds tests verifying embedded dist/assets exists and referenced assets are served correctly. |
| build.sh | Builds the web dashboard before cross-compiling the Go binary. |
| Makefile | Adds build-web target and makes build depend on it; extends clean. |
| Dockerfile | Adds a Node build stage to compile web assets before the Go build stage embeds them. |
|
|
||
| entries, err := fs.ReadDir(distFS, "assets") | ||
| if errors.Is(err, fs.ErrNotExist) { | ||
| t.Skip("skipping: web/dist/assets not built (run 'cd web && npm run build' or 'make build-web')") |
There was a problem hiding this comment.
These tests currently t.Skip when dist/assets is missing. That means the suite can still pass in environments that don’t run the web build step (e.g., CI/Windows or developers running go test ./... directly), which undermines the goal of catching the blank-page regression. Consider failing (require) when dist/assets is missing, or only skipping when an explicit opt-out env var is set (and default to failing in CI).
| t.Skip("skipping: web/dist/assets not built (run 'cd web && npm run build' or 'make build-web')") | |
| if os.Getenv("WAZA_SKIP_WEB_ASSET_TESTS") != "" { | |
| t.Skip("skipping: web/dist/assets not built (run 'cd web && npm run build' or 'make build-web'; set WAZA_SKIP_WEB_ASSET_TESTS='' to enforce failure)") | |
| } | |
| require.FailNow(t, "web/dist/assets not built (run 'cd web && npm run build' or 'make build-web'; or set WAZA_SKIP_WEB_ASSET_TESTS=1 to skip this test)") |
| if _, err := fs.ReadDir(distFS, "assets"); errors.Is(err, fs.ErrNotExist) { | ||
| t.Skip("skipping: web/dist/assets not built (run 'cd web && npm run build' or 'make build-web')") | ||
| } else if err != nil { |
There was a problem hiding this comment.
Same as above: t.Skip when dist/assets doesn’t exist means this check won’t enforce the embed/build invariant in setups that don’t build the web UI first. If this is intended to prevent regressions in packaging, it should fail by default (or at least fail under CI) so missing bundles are surfaced.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #107 +/- ##
=======================================
Coverage ? 72.97%
=======================================
Files ? 131
Lines ? 14817
Branches ? 0
=======================================
Hits ? 10812
Misses ? 3204
Partials ? 801
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…t#161) Closes microsoft#107 Adapts Azure ML's task evaluation rubrics as waza-compatible YAML configs for the prompt grader. ## Rubrics added | Rubric | Score type | Scale | Description | |--------|-----------|-------|-------------| | `task_adherence` | binary flag | 0.0 / 1.0 | 3-dimension eval (goal/rule/procedure); flagged=true on any material failure | | `task_completion` | binary | 0.0 / 1.0 | Was the task fully completed? Outcome-focused | | `intent_resolution` | ordinal 1-5 | 0.0–1.0 | How well did the agent resolve the user's intent? | | `response_completeness` | ordinal 1-5 | 0.0–1.0 | How thoroughly does the response cover ground truth? | ## Structure Each rubric YAML includes: - `evaluation_criteria` — detailed rubric text adapted from Azure ML `.prompty` files - `rating_levels` — scoring scale with descriptions - `score_normalization` — raw score → 0.0-1.0 mapping - `input_mapping` — waza graders.Context → rubric input mapping - `chain_of_thought` — step-by-step LLM judge instructions ## Source Adapted from [Azure/azure-sdk-for-python](https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/evaluation/azure-ai-evaluation/azure/ai/evaluation/_evaluators) evaluators: - `TaskAdherenceEvaluator` - `TaskCompletionEvaluator` - `IntentResolutionEvaluator` - `ResponseCompletenessEvaluator` > Note: The `examples/rubrics/README.md` is being created separately in microsoft#106. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Running
waza serveshows a blank white page in the browser.The root cause is a gap in the build pipeline:
web/dist/index.htmlis committed to git and references Vite-hashed JS/CSS bundles (e.g./assets/index-Dm42lpxa.js), but theweb/dist/assets/directory is gitignored — meaning those bundles are never checked in. None of the build scripts (Makefile,build.sh,Dockerfile) rannpm run buildinweb/before compiling the Go binary, so the//go:embed all:distdirective embeds anindex.htmlthat points at assets that don't exist.When the browser loads the page it gets the HTML fine, but every
<script>and<link>request for the missing JS/CSS hits the SPA fallback handler, which silently returnsindex.htmlagain instead of the actual bundle — resulting in a blank page with no visible errors.Fix
Added a web frontend build step (
npm ci && npm run build) to all three build paths so the dashboard assets are always compiled before the Go binary embeds them:build-webtarget;buildnow depends on it;cleanremovesweb/dist/assetsnode:22-alpinemulti-stage build that compiles web assets before the Go stageTesting
Added two new tests in
internal/webserver/server_test.gothat would have caught this bug:TestEmbeddedAssetsDirectoryContainsBundlesdist/assets/exists in the embedded FS and contains at least one.jsand one.cssfileTestIndexHTMLReferencesExistingAssetsindex.htmlfor<script src>and<link href>references, then verifies each asset is served with the correct content type — not the HTML fallback that causes the blank pageAll 13 webserver tests pass. No changes to application logic.