fix: Build embedded UI from local source#6526
Conversation
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 GitHub
Your 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".
| 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 👍 / 👎.
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
v0.64-branch.make build-uito build the checked-outui/source and copy the generated build intosdk/python/feast/ui/build.build-ui-localas an alias for the same build path.masterso mocked config does not accidentally mount MCP routes in unit tests.masterREST route registration test simplification so the test verifies router inclusion directly instead of depending on mockedRestRegistryServerconstruction side effects.masterallowlist comment for the OpenLineage placeholder API key sodetect-secrets --all-filespasses on the release branch.Why
feast uipackages the embedded React app fromsdk/python/feast/ui/build. The previous release build target pulled@feast-dev/feast-ui --latestfrom npm, but npm's latest published package is still0.57.0. That stale UI treatsregistryPathas a monolithic registry blob URL, so with the newer Python server generating/api/v1, it requestsGET /api/v1and 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-branchunit tests use aMagicMockconfig. Without requiringmcp.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 matchesmasterby verifyingregister_all_routesdirectly.The OpenLineage manifest change matches
master; it is a placeholder value, not a real secret.Fixes #6519.
Validation
make -n build-uipython3 -m py_compile sdk/python/tests/unit/api/test_api_rest_registry_server.py sdk/python/feast/api/registry/rest/rest_registry_server.pyI could not run the full UI build locally because
yarnis not installed in this shell. I also could not run the targeted Python test locally becauseuvis not installed in this shell, and I could not runpre-commitlocally becausepre-commitis not installed in this shell.