chore(helm): Add GatewayAPI route support to helm chart

[wiiaam]

Description

Adds support for creating a GatewayAPI HTTPRoute (or other routes)

Follows existing patterns in mainstream helm charts, using a main route and allowing the user to configure more routes if needed

• Fixes Add GatewayAPI route support to helm chart #2543

How Has This Been Tested?

Verified output with helm template and tested on my cluster

Checklist:

• I have read and followed the contribution guidelines.
• Disclosed any use of AI (see our policy)
• I have updated the documentation accordingly.
• All new and existing tests passed.
• Successful build pnpm build
• Translation keys pnpm i18n:extract
• Database migration (if required)

Summary by CodeRabbit

• New Features

  • Added Gateway API HTTPRoute support with configurable hostnames, path matching, HTTPS redirect, parent refs, additional rules, and custom filters.
  • New route configuration in chart values for enabling/disabling routes and fine-grained routing control; added top-level resources placeholder.
  • Chart version updated to 3.2.0.

• Documentation

  • README updated with expanded route configuration options and examples.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds Gateway API HTTPRoute support to the seerr-chart Helm chart: new Helm template templates/route.yaml, new route.main defaults in values.yaml, README updates documenting route options, and Chart version bumped to 3.2.0.

Changes

Cohort / File(s)	Summary
Gateway Route Template charts/seerr-chart/templates/route.yaml	New Helm template that renders HTTPRoute-style resources from values.route.*, honoring enabled, apiVersion/kind, parentRefs, hostnames, annotations/labels, additionalRules, filters, matches, httpsRedirect, and backend refs.
Chart Values charts/seerr-chart/values.yaml	Adds route.main configuration block with defaults (enabled, apiVersion, kind, annotations, labels, parentRefs, hostnames, additionalRules, filters, matches with PathPrefix, httpsRedirect) and a top-level resources: {} placeholder.
Documentation charts/seerr-chart/README.md	Updated Values table with new route.main.* entries and bumped chart/app version badges (Chart version 3.2.0, AppVersion remains v3.0.1).
Chart Metadata charts/seerr-chart/Chart.yaml	Chart version incremented from 3.1.0 to 3.2.0.

Sequence Diagram(s)

sequenceDiagram
    participant Helm as Helm chart
    participant K8s as Kubernetes API
    participant GW as Gateway controller
    participant Svc as Seerr backend

    Helm->>K8s: Render & apply HTTPRoute (templates/route.yaml using values.route.main)
    K8s->>GW: Inform Gateway controller of new/updated HTTPRoute
    GW->>K8s: Resolve parentRefs & attach HTTPRoute to Gateway
    GW->>Svc: Forward traffic per HTTPRoute rules (matches, filters, redirects, backendRefs)

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested reviewers

• fallenbagel
• sudo-kraken
• 0xSysR3ll

Poem

🐰 I hopped through values, stitched a route so neat,
Helm shaped the templates, and Kubernetes took a seat,
ParentRefs nudged gates to swing open wide,
Redirects and matches let traffic glide,
A rabbit's cheer — deployments stride with pride!

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title accurately describes the main change—adding GatewayAPI route support to the Helm chart—and aligns with the primary objective stated in the PR description and linked issue.
Linked Issues check	✅ Passed	The changes fully implement the requirements from issue #2543: the route.yaml template creates HTTPRoute resources, values.yaml provides configuration options, and README.md documents the new route.main configuration keys.
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing GatewayAPI route support; the Chart.yaml version bump is a standard accompaniment to new feature additions.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@charts/seerr-chart/templates/route.yaml`:
- Around line 30-36: The httpsRedirect branch currently emits a filters block
with a RequestRedirect but omits any user-supplied route.matches, causing the
redirect to apply globally; update the template so when $route.httpsRedirect is
true it also preserves and renders existing route.matches (the same values used
when httpsRedirect is false) before the filters: RequestRedirect block (ensure
correct YAML indentation and handle empty/nil $route.matches gracefully) so the
redirect only applies within the original match scope.
- Around line 4-50: The template emits HTTP-only fields for every route kind
causing invalid manifests; update the logic around $route.kind (used in the kind
default and rendering) to branch per supported Gateway API kinds: allow
rules[].matches, rules[].filters and the RequestRedirect filter only when
$route.kind is "HTTPRoute" or "GRPCRoute", and for
"TCPRoute"/"UDPRoute"/"TLSRoute" render only rules[].backendRefs (and optional
name) without matches/filters or RequestRedirect; also when $route.httpsRedirect
is set, ensure the RequestRedirect filter is applied inside the same rule
alongside any configured $route.matches (not as a standalone unconditional rule)
so redirects respect match conditions; adjust any documentation/defaults to
constrain allowed kinds accordingly.

[coderabbitai]

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@charts/seerr-chart/templates/route.yaml`:
- Around line 4-5: The template unconditionally emits HTTP-specific fields
(matches, filters, RequestRedirect) even when $route.kind can be
TCPRoute/UDPRoute/TLSRoute, causing Gateway API validation failures; update the
route.yaml template to branch on $route.kind (the $route.kind/$route.apiVersion
values) and only render matches, filters and RequestRedirect when the kind is an
HTTP-compatible type (e.g., "HTTPRoute" or "GRPCRoute"), or alternatively
restrict the allowed default/values for $route.kind in the chart defaults/docs
to HTTPRoute/GRPCRoute; locate the conditional blocks that output
matches/filters/RequestRedirect and wrap them in checks against $route.kind (or
change defaults) so non-HTTP kinds do not receive invalid fields.

[Copilot]

Pull request overview

This PR adds Gateway API HTTPRoute support to the Seerr Helm chart, enabling users to create Gateway API route resources alongside or instead of traditional Ingress resources. The implementation follows a flexible multi-route pattern where users can define multiple named route configurations (e.g., route.main, route.http, route.https) for different routing scenarios.

Changes:

• Added new Gateway API route template supporting HTTPRoute and other route kinds with configurable apiVersion
• Added comprehensive route configuration options in values.yaml including parentRefs, hostnames, filters, matches, and HTTPS redirect support
• Bumped chart version from 3.1.0 to 3.2.0

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
charts/seerr-chart/templates/route.yaml	New template that creates Gateway API route resources with support for multiple named routes, HTTPS redirects, and flexible rule configuration
charts/seerr-chart/values.yaml	Added route configuration section with main route defaults and comprehensive options for Gateway API integration
charts/seerr-chart/Chart.yaml	Version bump to 3.2.0 reflecting the new feature addition
charts/seerr-chart/README.md	Auto-generated documentation updates reflecting the new route configuration options

Comments suppressed due to low confidence (5)

charts/seerr-chart/templates/route.yaml:29

• The placement of additionalRules before the main rule creates a problematic ordering. When additionalRules are present, they will be rendered first, followed by either the httpsRedirect rule or the normal backend rule. This means the main route rule is always appended last, which may not match user expectations. Consider either: (1) placing additionalRules after the main rule, or (2) not generating a default rule when additionalRules are present and the user wants full control, or (3) documenting this behavior clearly in values.yaml that additionalRules come before the main rule.

  rules:
    {{- if $route.additionalRules }}
    {{- tpl (toYaml $route.additionalRules) $ | nindent 4 }}
    {{- end }}

charts/seerr-chart/values.yaml:144

• The documentation comment is misleading. It says "create a new route object under the main route" but the actual structure is to create a sibling route object at the same level as 'main' in the route map (e.g., route.http for HTTP and route.https for HTTPS redirect). The phrase "under the main route" suggests nesting within the main object, which is not the case. Consider clarifying to: "To redirect to HTTPS, create a separate route object (e.g., route.http) alongside the main route with this option enabled."

    # -- To redirect to HTTPS, create a new route object under the main route and enable this option.
    # This should only be used with HTTP-like routes, such as HTTPRoute or GRPCRoute.
    # [Reference]( https://gateway-api.sigs.k8s.io/guides/http-redirect-rewrite/ )
    httpsRedirect: false

charts/seerr-chart/templates/route.yaml:55

• When additionalRules are provided, a default rule (either httpsRedirect or normal backend) is always appended after them. This means users cannot use additionalRules alone without getting an extra rule they may not want. Consider adding a flag (e.g., 'defaultRule: true') that allows users to disable the automatic default rule generation when they want full control via additionalRules. Alternatively, document this behavior clearly in values.yaml.

  rules:
    {{- if $route.additionalRules }}
    {{- tpl (toYaml $route.additionalRules) $ | nindent 4 }}
    {{- end }}
    {{- if $route.httpsRedirect }}
    - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 301
      {{- with $route.matches }}
      matches:
        {{- toYaml . | nindent 8 }}
      {{- end }}
    {{- else }}
    - backendRefs:
        - name: {{ include "seerr.fullname" $ }}
          port: {{ $.Values.service.port }}
          group: ''
          kind: Service
          weight: 1
      {{- with $route.filters }}
      filters:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with $route.matches }}
      matches:
        {{- toYaml . | nindent 8 }}
      {{- end }}
    {{- end }}

charts/seerr-chart/values.yaml:143

• There's an extra space in the markdown link syntax. The reference link has a space after the opening parenthesis: '[Reference]( https://...' should be '[Reference](https://...' without the space. This may cause the link to not render properly in some markdown parsers.

    # [Reference]( https://gateway-api.sigs.k8s.io/guides/http-redirect-rewrite/ )

charts/seerr-chart/templates/route.yaml:7

• The template uses 'template' instead of 'include' for the fullname helper, which is inconsistent with other templates in this chart. The ingress template (ingress.yaml:5,36) and the route template itself (line 42) use 'include'. The 'include' function is preferred in Helm as it allows piping the output to other functions. This should be changed to: {{ include "seerr.fullname" $ }}

  name: {{ template "seerr.fullname" $ }}{{ if ne $name "main" }}-{{ $name }}{{ end }}

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[M0NsTeRRR]

Thanks for your contribution !