feat(ui-react): deploy the React UI via the MINT chart (9.0.0-beta.3)

[mosoriob]

PR 2 of 2 for mintproject/monorepo#57. The monorepo half (mintproject/monorepo#58) is merged, and this pins the image it published.

Adds a ui_react component that deploys the React UI alongside the legacy ui rather than replacing it. ui.yaml, ui-config.yaml and ingress-ui.yaml are byte-for-byte unchanged — verified with git diff origin/main. The cutover is a separate decision.

Disabled by default. The chart is consumed by deployments whose upgrade timing isn't controlled here; an enabled-by-default component would spin up a deployment and an ingress — and hit the required client ID check — on the next routine upgrade for operators who never asked for the new UI.

Shape

• Own host, next.mint.local. The application is built to be served from the root, so a path prefix would need a build-time base path — meaning the Kubernetes image could no longer be the same artifact Vercel tests.
• Configuration passed as environment variables, not a rendered config file. The image's entrypoint owns the config shape and its defaults, so a key omitted here falls back to that default instead of being blanked out, and the same image behaves identically under Helm, docker run, or Vercel.
• A checksum/config annotation rolls the pods when the ConfigMap changes, since the entrypoint reads the environment only at startup.
• Endpoints derive from each component's own ingress declaration, with per-key overrides taking precedence, so hostnames already in values aren't restated with no way to keep them in sync.
• Its own OAuth2 client ID, no default; rendering fails with an explicit message when enabled without one. An identity provider registers one callback URL per client, so sharing the legacy UI's client would either be rejected or tempt an operator into repointing it — silently breaking login on the production UI.

Two legacy defects corrected rather than carried forward

Empty host list. This turned out to be worse than the issue described. first on an empty list returns nil rather than erroring, so the legacy template silently emits window.REACT_APP_GRAPHQL_ENDPOINT = "/v1/graphql" — a malformed relative URL, with no failure anywhere. The new template guards the list and omits the key entirely, letting the application fall back to its own default.

Hasura URL. The legacy template emits a bare hostname plus a separate REACT_APP_GRAPHQL_ENABLE_SSL boolean; every other endpoint gets a full URL. The new UI needs a complete URL, so the scheme is prepended.

Verification

helm template / helm lint, checked as behaviour rather than assumed:

Case	Result
Endpoint derivation	http://graphql.mint.local/v1/graphql, model-catalog and ensemble-manager derive with their api_version
Override precedence	explicit data_catalog_api wins over derivation
TLS on a component	scheme becomes https
Component disabled	its key is omitted, not emitted broken
Empty hosts	renders fine, key omitted (legacy silently emits a malformed URL)
Enabled without client_id	render fails with an explicit message
Default values	zero ui_react objects rendered

A divergence from the issue's testing plan, deliberate

mintproject/monorepo#57 says to add a values file "to the existing set" for chart-testing. That set doesn't exist as assumed: tests/*.yaml is referenced by nothing — not ct.yaml, not linter.yaml, not the Makefile — so ct install only ever ran default values. Extra values files have to live in charts/mint/ci/.

Adding anything to ci/ makes chart-testing install once per file there instead of the default run, so ci/default-values.yaml is included to preserve coverage that was previously implicit and would otherwise have been silently dropped.

The required-client-ID failure is not covered by CI. #57 claims this seam covers it, but chart-testing has no expect-failure mode — a values file omitting client_id would just turn CI red. The fail is still correct; it's simply unverified by CI, and the values file says so rather than reading as covered.

Note also that ct install now pulls the pinned image into kind on every chart PR, so chart CI gains a dependency on that image staying pullable.

Image tag

Pinned to 55a3472a975b11af51fcfedf3f6f9b66db024bf0 — the merge commit of mintproject/monorepo#58 on develop. Verified present on Docker Hub for both amd64 and arm64 before packaging.

This is a monorepo SHA, not a submodule SHA: this application lives in-tree. The existing image-tag bump automation resolves only submodule SHAs and will not update this component — it must be set by hand, and the values comment says so.

Not covered

No container is run anywhere in CI. The entrypoint generating the config at startup and the nginx SPA fallback were smoke-tested by hand against this image, but nothing automated exercises them — an explicit trade recorded in #57, and the weakest point in the plan.

Closes mintproject/monorepo#57