Wire HTTPRoute defaults through web context#1063
Wire HTTPRoute defaults through web context#1063Bafbi wants to merge 1 commit intoInseeFrLab:mainfrom
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (5)
📝 WalkthroughWalkthroughThe pull request introduces a new optional Changes
Sequence DiagramsequenceDiagram
actor API as Onyxia API
participant Adapter as onyxiaApi Adapter
participant Region as DeploymentRegion
participant Context as XOnyxiaContext
participant Helm as Helm Values
API->>Adapter: /public/configuration with httpRoute
Adapter->>Region: Map apiRegion.services.expose.httpRoute
Region->>Context: Region.httpRoute → k8s.httpRoute
Context->>Helm: Override defaults with k8s.httpRoute
Helm->>Helm: Generate helmValues.httpRoute.parentRefs
Estimated Code Review Effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
web/src/core/ports/OnyxiaApi/DeploymentRegion.ts (1)
14-24: Consider extracting a sharedHttpRouteParentRef/HttpRouteConfigtype.Line 14 introduces a shape that is duplicated across API, deployment-region, and context types. Centralizing it would reduce type drift risk.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@web/src/core/ports/OnyxiaApi/DeploymentRegion.ts` around lines 14 - 24, Extract a shared type for the HTTP route shape and replace duplicated inline definitions: create and export a HttpRouteParentRef (with fields name, namespace?, sectionName?, port?) and a HttpRouteConfig (with enabled: boolean and parentRefs: HttpRouteParentRef[]) and then update the existing httpRoute property in DeploymentRegion (and the corresponding API and context types) to use HttpRouteConfig | undefined instead of the inline object to prevent type drift and ensure reuse.helm-chart/templates/httproute.yaml (1)
6-8: Add explicitrequiredchecks for service ports to fail fast with clearer errors.Right now port lookups rely on implicit value presence. Adding
required(...)here makes misconfiguration errors immediate and actionable during rendering.♻️ Proposed refactor
-{{- $svcPortApi := .Values.api.service.port -}} -{{- $svcPortWeb := .Values.web.service.port -}} -{{- $svcPortOnboarding := .Values.onboarding.service.port -}} +{{- $svcPortApi := required "api.service.port is required when httpRoute.enabled=true" .Values.api.service.port -}} +{{- $svcPortWeb := required "web.service.port is required when httpRoute.enabled=true" .Values.web.service.port -}} +{{- $svcPortOnboarding := .Values.onboarding.service.port -}} @@ - port: {{ $svcPortOnboarding }} + port: {{ required "onboarding.service.port is required when onboarding.enabled=true and httpRoute.enabled=true" $svcPortOnboarding }}Also applies to: 52-52
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@helm-chart/templates/httproute.yaml` around lines 6 - 8, Replace implicit port lookups with Helm's required(...) wrapper so rendering fails fast with a clear message; specifically update the variable assignments for $svcPortApi, $svcPortWeb, and $svcPortOnboarding to use required("missing service port for api|web|onboarding", .Values.api.service.port) (and analogous messages for web and onboarding) and apply the same required(...) check to the other port usage referenced around the second occurrence (the one at the other port lookup on line ~52). Ensure each required call uses a distinct, descriptive message mentioning the service name.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@helm-chart/templates/httproute.yaml`:
- Around line 6-8: Replace implicit port lookups with Helm's required(...)
wrapper so rendering fails fast with a clear message; specifically update the
variable assignments for $svcPortApi, $svcPortWeb, and $svcPortOnboarding to use
required("missing service port for api|web|onboarding",
.Values.api.service.port) (and analogous messages for web and onboarding) and
apply the same required(...) check to the other port usage referenced around the
second occurrence (the one at the other port lookup on line ~52). Ensure each
required call uses a distinct, descriptive message mentioning the service name.
In `@web/src/core/ports/OnyxiaApi/DeploymentRegion.ts`:
- Around line 14-24: Extract a shared type for the HTTP route shape and replace
duplicated inline definitions: create and export a HttpRouteParentRef (with
fields name, namespace?, sectionName?, port?) and a HttpRouteConfig (with
enabled: boolean and parentRefs: HttpRouteParentRef[]) and then update the
existing httpRoute property in DeploymentRegion (and the corresponding API and
context types) to use HttpRouteConfig | undefined instead of the inline object
to prevent type drift and ensure reuse.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a34e51fc-3827-4601-bdd1-b1053c2ba3a7
📒 Files selected for processing (9)
helm-chart/README.mdhelm-chart/templates/httproute.yamlhelm-chart/values.yamlweb/src/core/adapters/onyxiaApi/ApiTypes.tsweb/src/core/adapters/onyxiaApi/onyxiaApi.tsweb/src/core/ports/OnyxiaApi/DeploymentRegion.tsweb/src/core/ports/OnyxiaApi/XOnyxia.tsweb/src/core/usecases/launcher/decoupledLogic/computeHelmValues.test.tsweb/src/core/usecases/launcher/thunks.ts
64453a3 to
86f8599
Compare
|
No worries, I rebased my branch, also the checkbox was already mark as allowing edits. |



This pull request introduces support for exposing Onyxia using the Kubernetes Gateway API via
HTTPRoute, alongside documentation and code changes to enable this new feature. The most important changes are grouped below by theme.depend on #1061 , #InseeFrLab/onyxia-api#664
for #1062
Gateway API / HTTPRoute support
httproute.yamlHelm template to generateHTTPRouteresources whenhttpRoute.enabledis true, including validation ofparentRefsand backend routing for API, web, and onboarding services.values.yamlto include a newhttpRouteconfiguration section, allowing specification ofenabled,annotations,parentRefs, andhostnames.Documentation updates
README.mdwith instructions and examples for configuring Onyxia with the Gateway API (HTTPRoute), including sampleonyxia-values.yamlfiles and clear guidance on referencing cluster Gateways. [1] [2] [3]API and context propagation
httpRoutefields to the Onyxia API types, deployment region, and context interfaces in the web codebase to propagate Gateway API configuration from backend to frontend and service deployment logic. [1] [2] [3] [4] [5]Testing
computeHelmValuescorrectly supportshttpRoute.parentRefspropagation from thex-onyxiacontext, ensuring that the new configuration is handled as expected.Summary by CodeRabbit
Release Notes
New Features
Tests