radar-hub: stage 1.9.0-rc.3 (Hub 1.9.0-rc.3) with cloudAppURL and a port-forward mode

[hisco]

Stages Hub 1.9.0-rc.3, which adds:

• moving clusters from Radar Cloud to a self-hosted hub (skyhook-dev/radar-hub#274, skyhook-dev/radar-hub-web#329)
• a self-hosted hub with no public address, opened with kubectl port-forward (skyhook-dev/radar-hub#275, skyhook-dev/radar-hub#277, skyhook-dev/radar-hub-web#330)

Versions

• version: 1.9.0-rc.3, appVersion: 1.9.0-rc.3. Chart and Hub versions match from this release on; the Hub skips 1.8.0 so they can. 1.9.0-rc.2 is not published from this PR.
• Merge only after ghcr.io/skyhook-dev/radar-hub:1.9.0-rc.3 and ghcr.io/skyhook-dev/radar-hub-web:1.9.0-rc.3 are published. Merging publishes the chart. As a pre-release it isn't the default for helm install.

New values

hub.cloudAppURL sets RADAR_HUB_CLOUD_APP_URL: the Radar Cloud web app the hub's licence belongs to, used only to build links into Cloud. Empty keeps the Hub's default, https://app.radarhq.io. The schema accepts only a bare http(s) origin, the same rule the Hub enforces at startup. It stays set when hub.airGapped is on, since it makes no calls.

A localhost hub.publicURL (localhost, *.localhost, 127.x, [::1], 0.0.0.0, [::], any port) means the hub has no address agents can use; the hub works that out itself too. With no Ingress, HTTPRoute or LoadBalancer in front it also means the hub is opened with port-forward: the chart sets RADAR_HUB_BROWSER_ONLY_URL, requires https and web.tls.selfSigned, and NOTES print the port-forward command for the URL's port (with --address for loopback IPs other than 127.0.0.1 and ::1). There is no mode flag.

localCluster.id with localCluster.token, or localCluster.existingSecret and existingSecretKey, has the hub register the cluster it runs in. An inline token lives in the chart Secret, whose checksum rolls the hub pod when the token changes.

web.tls.inCluster keeps the web Service's https port, the pod's 8443 listener and RADAR_HUB_IN_CLUSTER_AGENT_URL on behind an Ingress or Gateway. The same listener is on whenever web.tls.selfSigned, a localhost hub.publicURL or localCluster is set. Agents in the hub's own cluster dial it, so switching a trial to Ingress doesn't disconnect them. The readiness probe and RADAR_HUB_INSECURE_SKIP_VERIFY still follow web.tls.selfSigned only.

NOTES print the exact in-cluster agent address, honouring fullnameOverride, service.web.tlsPort and clusterDomain.

Where to look hardest

templates/_helpers.tpl radar-hub.inClusterTLS, and the Ingress renders with and without it. A plain Ingress install without the new values renders the same as before apart from the version.

Also fixed

The self-signed certificate host drops IPv6 brackets, so https://[::1]:8443 and public IPv6 URLs get a valid certificate (OpenSSL rejected IP:[::1]).

Known side effect

With service.web.type=LoadBalancer and any of the in-cluster triggers set, the self-signed 443 is also exposed on the load balancer, since it's the same Service.

Testing

• helm lint with both CI values files: pass
• helm unittest charts/radar-hub: 19/19
• tests/render-matrix.sh: all 209 checks pass, including the cloudAppURL cases, every localhost form and lookalikes that must not match, the https and self-signed guards and their Ingress/Gateway/LoadBalancer exemption, localCluster inline and existing Secret, web.tls.inCluster behind Ingress, and the NOTES port-forward and --address lines.
• On kind: a hub from this chart with hub.publicURL=https://localhost:8443 connected its own cluster with no DNS or load balancer. After helm upgrade --reset-then-reuse-values to Ingress, agents on the in-cluster address stayed connected and port-forward mode ended by itself. A https://[::1]:8443 install came up with a valid certificate.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Stage Radar Hub 1.9.0-rc.1 with configurable Cloud app URL

✨ Enhancement ⚙️ Configuration changes 🧪 Tests 🕐 10-20 Minutes

AI Description

• Stages the chart and Hub defaults at aligned 1.9.0-rc.1 versions.
• Adds validated Cloud app URL configuration for links from self-hosted Hub deployments.
• Tests origin validation, environment wiring, defaults, and air-gapped behavior.

Diagram

graph TD
  A["Helm values"] --> B{"Valid origin?"} -->|Yes| D{"Value set?"} -->|Yes| F["Deployment env"] --> G["Cloud links"]
  B -->|No| C["Render rejected"]
  D -->|No| E["Hub default"] --> G

Loading

High-Level Assessment

The PR uses the appropriate Helm-native configuration path: declare the value, constrain it through JSON Schema, conditionally wire it into the container, and verify behavior through render tests. Hard-coding the URL or deriving it from the license server would reduce deployment flexibility and conflict with the Hub's separate endpoint semantics.

Files changed (5) +30 / -2

Enhancement (1) +6 / -0

deployment-hub.yamlPass the configured Cloud app origin to Hub +6/-0

Pass the configured Cloud app origin to Hub

• Conditionally adds RADAR_HUB_CLOUD_APP_URL to the Hub container when cloudAppURL is non-empty. The setting remains available in air-gapped deployments because it only controls generated links.

charts/radar-hub/templates/deployment-hub.yaml

Tests (1) +9 / -0

render-matrix.shCover Cloud app URL validation and deployment wiring +9/-0

Cover Cloud app URL validation and deployment wiring

• Adds render checks for valid origins, ports, missing schemes, and forbidden paths. It also verifies environment-variable presence, default omission, and preservation under air-gapped configuration.

charts/radar-hub/tests/render-matrix.sh

Other (3) +15 / -2

Chart.yamlStage chart and Hub release 1.9.0-rc.1 +2/-2

Stage chart and Hub release 1.9.0-rc.1

• Advances both the chart version and application version to 1.9.0-rc.1, aligning their release numbering and default image tags.

charts/radar-hub/Chart.yaml

values.schema.jsonValidate cloudAppURL as an HTTP(S) origin +5/-0

Validate cloudAppURL as an HTTP(S) origin

• Defines cloudAppURL as a string accepting either an empty value or a bare HTTP(S) origin without credentials, query parameters, fragments, or paths.

charts/radar-hub/values.schema.json

values.yamlExpose and document the Cloud app URL setting +8/-0

Expose and document the Cloud app URL setting

• Adds hub.cloudAppURL with an empty default and documents its link-building purpose, validation constraints, default behavior, and relationship to licenseServer.

charts/radar-hub/values.yaml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Invalid ports use default Cloud ✓ Resolved 🔗 Cross-repo conflict ≡ Correctness

Description

The cloudAppURL schema pattern accepts malformed authorities such as https://:, nonnumeric ports
such as https://app.example:abc, and out-of-range ports such as https://app.example:99999
because it permits arbitrary colons without requiring a valid host or port. When one of these values
is configured, Helm renders it unchanged into RADAR_HUB_CLOUD_APP_URL, Hub's parseOrigin accepts
and publishes it, and radar-hub-web may have its browser URL constructor reject it and silently
substitute https://app.radarhq.io, causing links to target a different Cloud deployment.

Code

charts/radar-hub/values.schema.json[343]

+          "pattern": "^$|^https?://[^/?#@\\s]+/*$",

Evidence

The chart documents cloudAppURL as a bare origin, but the schema character class only excludes
paths, credentials, whitespace, queries, and fragments; it still permits colon-containing
authorities without requiring a host, numeric port, or valid port range. The deployment template
emits every accepted nonempty value unchanged as the Hub environment variable, and Hub validates
only the scheme, hostname, and URL components before publishing it as cloud_app_url. Radar-hub-web
then parses that field with the browser URL implementation and returns the production default if
parsing throws, while the added chart tests cover only a missing scheme and a conventional path
rather than malformed hosts or ports.

helm-charts -> radar-hub
helm-charts -> radar-hub-web
charts/radar-hub/values.schema.json[341-345]
charts/radar-hub/templates/deployment-hub.yaml[156-159]
charts/radar-hub/values.schema.json[341-344]
charts/radar-hub/templates/deployment-hub.yaml[156-158]
charts/radar-hub/tests/render-matrix.sh[67-71]
charts/radar-hub/values.yaml[304-310]
External repo: skyhook-dev/radar-hub, cmd/hub/main.go [1624-1634]
External repo: skyhook-dev/radar-hub, internal/server/config_handler.go [166-173]
External repo: skyhook-dev/radar-hub-web, src/lib/hubMove.ts [14-31]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`hub.cloudAppURL` accepts malformed HTTP(S) authorities, including missing hosts, nonnumeric ports, and ports outside 1–65535. These values render successfully and pass unchanged through the Hub, but radar-hub-web may reject them and fall back to the production Radar Cloud URL.
## Fix Focus Areas
- charts/radar-hub/values.schema.json[341-345]
- charts/radar-hub/tests/render-matrix.sh[67-72]
## Recommended Fix
Strengthen validation so the value is either empty or a syntactically valid HTTP(S) origin with a nonempty host, an optional numeric port within the valid TCP range, and no credentials, path, query, fragment, or backslash. Preserve support for origins without ports and valid hostname, localhost, port, and IPv6 origins, including `http://localhost:3000`. Add render-matrix rejection cases for missing hosts, nonnumeric and out-of-range ports, malformed authorities, and backslash-based paths.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗