Files
deepseek-harness/web.cordis.patch.yml
dsh-relay 0af110766d
Sync upstream and build images / sync-and-build (push) Successful in 38m42s
ci: pick the webserver bind address from the installed schema
The 0.2.1-alpha.2 fix rendered `host` onto the container's own address
unconditionally. Every earlier release still validates it against the union of
the two literals 127.0.0.1 and 0.0.0.0, so those images now die in the boot
smoke test with

  @deepseek-ai/dsh-host-webserver: ValidationError: invalid config:
    - $.host expected "127.0.0.1" | "0.0.0.0" but got "172.17.0.22" (at host)

and their refresh rebuilds -- which the recipe-hash change re-queued anyway --
can no longer succeed. Probe the installed webserver schema instead: where it
rejects the unspecified address render the container's own IPv4, otherwise keep
0.0.0.0 so older versions build exactly as they did before. The probe is
overridable through DSH_INSTALL_ROOT so both branches are testable.
2026-10-13 21:09:56 -04:00

19 lines
1003 B
YAML

# Launcher patch layer for containerized `dsh web` (passed via --patch).
#
# The host is a placeholder, not a value. From 0.2.1-alpha.2 the webserver
# schema rejects the unspecified address outright ("host … is an unspecified
# (wildcard) address, which is not supported … bind one concrete IPv4 or IPv6
# address of a local interface instead") and that check is a config transform,
# so no launcher flag can opt out of it; a static 0.0.0.0 — which the earlier
# `"127.0.0.1" | "0.0.0.0"` schema accepted — now fails the boot smoke test.
#
# The image entrypoint renders this file at startup: onto the container's own
# IPv4 address when the installed schema rejects the wildcard, otherwise back
# to 0.0.0.0 so older images build unchanged. A port published on the Docker
# host still reaches the UI either way, because the published port is forwarded
# to exactly that address. Set DSH_WEB_HOST to pin a different address.
- id: webserver
config:
host: __DSH_BIND_HOST__
port: 3080