fix(registry): emit path-only URL for routed apps#202
Merged
Conversation
Routed apps now generate `url = "/{app_id}/"` instead of
`url = "https://{{domain}}/{app_id}/"`. Browser resolves the href
against the current origin, so the dashboard card works under every
configured hostname (mDNS, VPN FQDN, DHCP-DNS) — completing the
multi-hostname access migration for container apps.
Non-routed (direct-port) apps continue to use the {{domain}} template
because a port can't be expressed as a path.
The previous bumpversion commit didn't refresh uv.lock; the ruff-check pre-commit hook (which builds the package) syncs it on next run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Completes the multi-hostname access migration for container apps.
Problem
container-packaging-toolsgenerated TOML registry entries with absolute URLs:homarr-container-adapterexpanded{{domain}}at load time to the device's mDNS hostname (e.g.halosdev.local) and wrote that into the Homarr app row. The card href was then bound to one hostname — so when a user accessed Homarr athttps://10.84.77.127(or any other configured hostname), the Signal K Server card still linked tohttps://halosdev.local/signalk-server/, defeating the multi-hostname access design.This affected every routed container app (Signal K Server, InfluxDB, Grafana, AvNav, OpenCPN, …) because they all share this generator. The path-only-href migration touched the homarr fork, the SK-discovery branch of the adapter,
halos-cockpit-config/cockpit.toml(hand-written), and Traefik routing — but the container-packaging-tools generator was missed.Fix
Routed apps now emit a path-only URL:
The browser resolves the href against the current origin, so the same card works under every configured hostname (mDNS, VPN FQDN, DHCP-DNS) without any
{{domain}}template expansion.Non-routed (direct-port) apps continue to use
{{domain}}because a TCP port can't be expressed as a path.Tests
test_url_with_routing_is_path_only(renamed fromtest_url_with_routing_uses_path_redirect) asserts:url = "/{app_id}/"— no scheme, no hostname# Path-only URLdocumentation comment{{domain}}does not appear anywhere in the generated TOMLtest_url_with_routing_uses_app_idupdated to expecturl = "/{app_id}/".563 unit tests + 27 integration tests pass. Pre-existing typecheck diagnostics in
converters/casaos/transformer.pyandrouting.pyare unchanged (present on main, not introduced by this PR).Follow-up
After this lands and a new
marine-signalk-server-containerpackage is rebuilt + pushed to apt.hatlabs.fi, flash the next halos-pi-gen image to verify the Signal K Server card on Homarr renders path-only and works across hostnames.