chore: bump nebari-landing chart to v0.1.0-alpha.5

[viniciusdc]

Description

Upgrades the nebari-landing helm chart to v0.1.0-alpha.5.

Full changelog: nebari-dev/nebari-landing@v0.1.0-alpha.4...v0.1.0-alpha.5

Notes on upstream changes that affect us

The headline change in alpha.5 is dropping the oauth2-proxy sidecar in favor of a pure SPA PKCE/S256 flow handled client-side by keycloak-js (see nebari-landing#72). The chart no longer renders an oauth2-proxy container or a confidential OIDC client; the frontend Service now points directly at nginx on port 8080.

Concrete effects on this Application's values block:

• Removed frontend.oauth2Proxy.oidcIssuerUrl — the entire frontend.oauth2Proxy.* key is gone from the chart in alpha.5, so this override is dead config.
• frontend.keycloak.{url,realm} is unchanged — still rendered into /config.json for the browser.
• webapi.*, nebariApp.enabled: true, httpRoute.*, and redis.auth.existingSecret are unchanged.

Out of scope (worth a separate look)

• The NebariApp template still sets auth.enabled: true, so the operator continues to provision the primary (formerly oauth2-proxy) OIDC client even though nothing consumes it anymore. The SPA client provisioned via spaClient.enabled is the one actually used.

[viniciusdc]

Tested end-to-end on the Hetzner cluster (nic-nebari). Pinned NIC to this branch via openteams-ai/nic-deploy#3, ran the deploy workflow, and let ArgoCD reconcile.

Post-deploy state matches what alpha.5 promises:

• Frontend pod is single-container nginx. No oauth2-proxy sidecar, no wait-for-keycloak init.
• Frontend Service is on 8080/TCP (was 4180 in the oauth2-proxy era).
• Single nebari-landing NebariApp CR. Single HTTPRoute (nebari-landing-route) with one rule routing / to nebari-landing-frontend:8080. No /oauth2/* sibling.
• auth.enforceAtGateway: false and no SecurityPolicy for landing. Auth is in-browser.
• Frontend /config.json carries clientId: nebari-system-nebari-landing-spa (public PKCE client). Nginx config has the WebSocket upgrade map for /api/v1/ws.
• Image overrides on the deploy side dropped cleanly. Pods are running quay.io/nebari/nebari-landing:latest and quay.io/nebari/nebari-webapi:latest.

Logs are clean. Frontend serves /, /assets/*, /config.json, /api/v1/services, /api/v1/notifications with 200s after login. Webapi health-checker is happy across all 5 downstream services, no JWT validation errors, no Redis WRONGPASS.

The orphan oauth2-proxy confidential client I flagged in the PR description is confirmed on the live deploy. Filed separately as nebari-dev/nebari-landing#81. Not blocking this PR.

[dcmcand]

Approving.

Highlights:

• Inline comment in nebari-landingpage.yaml explaining why the image tag is pinned (chart defaults to :latest, would silently float on pod restart) is exactly the kind of "non-obvious why" comment worth keeping.
• Stale NOTE block in writer.go about oidcIssuerUrl collapsing to a relative path is correctly removed alongside upstream's drop of oauth2-proxy.
• PR body is excellent - links the upstream release and PR, enumerates exactly which value-block keys change, and explicitly flags an out-of-scope item.
• Test diff is symmetric with the template change.

One sanity check (non-blocking): chart targetRevision uses v0.1.0-alpha.5 (with v) while image tags use 0.1.0-alpha.5 (no v). That mirrors how upstream tags git releases vs container images, so it's almost certainly correct - just worth confirming the published image tags exist if you haven't already deployed.

Stylistic (not blocking): the version literal is duplicated three times across the template. A TemplateData.LandingChartVersion field would keep chart revision and image tags in lockstep on future bumps.

Follow-up: the out-of-scope NebariApp.auth.enabled: true item in the PR body is worth a separate issue so it doesn't get lost.

[viniciusdc]

I will close this one, since I will be opening a follow-up PR with a newer release of the landing page app, just waiting on finishing the review of nebari-dev/nebari-landing#84.