fix: Build embedded UI from local source - #6526
Conversation
Sorry, something went wrong.
Signed-off-by: Francisco Javier Arceo <farceo@redhat.com> (cherry picked from commit f09aa92)
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f89eb23bc4
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Sorry, something went wrong.
| cd $(ROOT_DIR)/sdk/python/feast/ui && yarn upgrade @feast-dev/feast-ui --latest && yarn install && npm run build --omit=dev | ||
|
|
||
| build-ui-local: ## Build Feast UI locally | ||
| cd $(ROOT_DIR)/ui && yarn install && npm run build --omit=dev |
There was a problem hiding this comment.
Build the UI from the release ref
Because this target now compiles the checked-out ui/ sources, the existing wheel workflow bundles the wrong UI when checkout_ref or the computed release tag differs from the workflow's initial checkout: .github/workflows/build_wheels.yml runs make build-ui at lines 64-65, then only later does git checkout "${CHECKOUT_REF:-$VERSION}" at lines 76-78 before building the wheel. In those release/verification runs, the Python package is built from the requested ref but sdk/python/feast/ui/build was produced from the earlier ref, so published wheels can contain a frontend from the wrong branch/tag.
Useful? React with 👍 / 👎.
Sorry, something went wrong.
Signed-off-by: Francisco Javier Arceo <farceo@redhat.com>
Signed-off-by: Francisco Javier Arceo <farceo@redhat.com>
Signed-off-by: Francisco Javier Arceo <farceo@redhat.com>
What changed
Why
feast ui packages the embedded React app from sdk/python/feast/ui/build. The previous release build target pulled @feast-dev/feast-ui --latest from npm, but npm's latest published package is still 0.57.0. That stale UI treats registryPath as a monolithic registry blob URL, so with the newer Python server generating /api/v1, it requests GET /api/v1 and receives a 404.
Building the embedded UI from the repo-local ui/ source keeps the frontend bundle aligned with the REST-backed Python UI server for the 0.64 release branch.
The test-only backports are included because v0.64-branch unit tests use a MagicMock config. Without requiring mcp.enabled is True, the mock is truthy and the server mounts MCP routes. After that guard, the route-path assertion still depends on mocked server construction, so this PR also matches master by verifying register_all_routes directly.
The OpenLineage manifest change matches master; it is a placeholder value, not a real secret.
Fixes #6519.
Validation
I could not run the full UI build locally because yarn is not installed in this shell. I also could not run the targeted Python test locally because uv is not installed in this shell, and I could not run pre-commit locally because pre-commit is not installed in this shell.