feat(charts/oma): support multiple ingress hosts - #352
Conversation
ingress.hosts (a list) takes precedence over the single ingress.host; all listed hosts are covered by one TLS cert (ingress.tls.secretName). Lets a deploy serve the app at more than one URL — e.g. a primary host plus a legacy/wildcard one — without a second Ingress. helm lint + template clean. Co-Authored-By: Claude <noreply@anthropic.com>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
Reviewer's guide (collapsed on small PRs)Reviewer's GuideAdd support for configuring multiple ingress hostnames via a new Flow diagram for ingress host selection logicflowchart TD
A[ingress.enabled true] --> B[Check ingress.hosts]
B -->|non-empty| C[Use ingress.hosts list]
B -->|empty or unset| D[Fallback to single ingress.host]
C --> E[Render tls.hosts with all hosts]
D --> E
C --> F[Render rules for each host]
D --> F
E --> G[Kubernetes Ingress TLS config]
F --> H[Kubernetes Ingress host rules]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Review limit reached
Next review available in: 33 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
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 |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- Consider filtering out empty values from
ingress.hostsandingress.host(or erroring when none are provided) so the generated Ingress doesn’t end up with blank host entries if both are unset or misconfigured.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider filtering out empty values from `ingress.hosts` and `ingress.host` (or erroring when none are provided) so the generated Ingress doesn’t end up with blank host entries if both are unset or misconfigured.
## Individual Comments
### Comment 1
<location path="charts/oma/templates/ingress.yaml" line_range="10-13" />
<code_context>
+ multiple hosts (one TLS cert covering all of them); or leave it unset and
+ set `ingress.host` for a single host. */}}
{{- if .Values.ingress.enabled }}
+{{- $hosts := (.Values.ingress.hosts | default (list .Values.ingress.host)) }}
apiVersion: networking.k8s.io/v1
kind: Ingress
</code_context>
<issue_to_address>
**issue:** Handle the case where both `ingress.hosts` and `ingress.host` are unset to avoid generating an invalid Ingress.
If `ingress.enabled` is true but both `ingress.hosts` and `ingress.host` are unset, `$hosts` becomes an empty list, so the `tls.hosts` and `rules` ranges render nothing and the Ingress is invalid and rejected by Kubernetes. Add a guard to ensure at least one host (e.g. `required` on `ingress.host` when `ingress.hosts` is empty) or fail fast with a template error when `$hosts` is empty.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| {{- $hosts := (.Values.ingress.hosts | default (list .Values.ingress.host)) }} | ||
| apiVersion: networking.k8s.io/v1 | ||
| kind: Ingress | ||
| metadata: |
There was a problem hiding this comment.
issue: Handle the case where both ingress.hosts and ingress.host are unset to avoid generating an invalid Ingress.
If ingress.enabled is true but both ingress.hosts and ingress.host are unset, $hosts becomes an empty list, so the tls.hosts and rules ranges render nothing and the Ingress is invalid and rejected by Kubernetes. Add a guard to ensure at least one host (e.g. required on ingress.host when ingress.hosts is empty) or fail fast with a template error when $hosts is empty.
2 participants
Adds
ingress.hosts(a list) alongsideingress.host; when set, all hosts are served under one TLS cert. Enables a deploy to expose the app at multiple URLs (e.g. a primary host + a legacy/wildcard host) without a second Ingress. Backward compatible (singlehoststill works).helm lint+helm templateclean.🤖 Generated with Claude Code
Summary by Sourcery
Support configuring multiple ingress hostnames for the OMA chart while preserving the existing single-host behavior.
New Features:
Enhancements: