Reconsider dev-watch smoke test: decouple frontend hot-reload testing from Kubernetes

[viniciusdc]

Once #55 lands we'll be using nebari-dev/action-nebari-sandbox (platform profile) as the standard way to bootstrap a cluster for integration tests. The intent is to eventually standardize that pattern across the nebari ecosystem org, so every repo that needs a real cluster in CI uses the same foundation.

That makes this a good moment to reconsider dev-watch-test.yml. Right now it spins up a full minikube stack just to check that swapping nginx for Vite works and then swapping back restores nginx. The actual feature being tested — minikube mount + iptables redirect + Vite HMR — is a local developer tool. It was never meant to run in CI against a real cluster, and the cluster is just overhead to exercise something that is fundamentally about the local dev loop.

I'm fairly sure I had a version of this that worked without a cluster at some point, running Vite directly against a lightweight mock backend. Something like that would be a much better fit: a Node.js dev server check that doesn't require provisioning anything. The cluster-based job could then be removed or at least made optional.

So the ask here is: once #55 is merged, explore replacing the minikube smoke test with a cluster-free frontend hot-reload check, and if that works, retire dev-watch-test.yml.

[viniciusdc]

I did start playing around with this idea a while back on this branch: feat/docker-compose-dev-stack. It has a docker-compose stack with Keycloak (real OIDC/PKCE, H2 in-memory so no postgres), a mock Go webapi that mirrors the real endpoints and reads from dev/manifests/test-nebariapps.yaml, and the frontend running Vite with source bind-mounted for HMR. No Kubernetes anywhere. make compose-up and you're done.

https://github.com/nebari-dev/nebari-landing/tree/feat/docker-compose-dev-stack

Worth picking that up as the starting point rather than starting from scratch.

[viniciusdc]

Talked this through with @jbouder, and we landed on a direction. Three options were on the table: Vite proxying to a live backend, a hybrid approach (real Keycloak in Docker + MSW for the API), or a fully mocked approach (MSW for both auth and API). Fully mocked is too much to maintain — keeping fake tokens and mock handlers in sync with the real API over time is a losing battle. Proxying to a live backend is simple, but it closes off testing options. So hybrid it is.

The plan:

• @jbouder will wire up the Docker-Compose pieces when he has availabilioty
• I'll add a Swagger/OpenAPI spec to the webapi (Go) that runs locally, and set up CI to regenerate and validate the MSW handlers against it, using this pattern:

https://mswjs.io/docs/recipes/keeping-mocks-in-sync#openapi-swagger

This way, the mocks stay decoupled from the backend while not drifting silently. As a side effect, the compose stack becomes a viable full-stack local dev path without Kubernetes, which is a nice door to leave open.