didericis
f9f27788db
tracker-policy-pr / check-pr (pull_request) Successful in 11s
test / integration-docker (pull_request) Successful in 17s
test / unit (pull_request) Successful in 43s
lint / lint (push) Successful in 56s
test / integration-firecracker (pull_request) Successful in 3m32s
test / coverage (pull_request) Successful in 23s
test / publish-infra (pull_request) Has been skipped
Answers the last open question in #392: DNS from inside a nested container was not a phantom, but it was also not a DNS problem. Public resolution fails there by design — everything egresses through the proxy — and the actual breakage was two missing pieces: - The proxy URL names `bot-bottle-gateway`, which resolves only through the bottle's own /etc/hosts. Containers got their own hosts file, so they failed at "Could not resolve proxy", which reads like broken DNS. base_hosts_file propagates the bottle's entries. - The gateway TLS-intercepts, so a container that does not trust the bottle's CA bundle fails with "unable to get local issuer certificate". The bundle is now mounted read-only and the usual env vars point at it, which covers curl, wget, python, and node without distro-specific trust commands. Verified on the macOS host by reproducing each failure and confirming that these three conditions applied by hand produced HTTP 200 from inside a nested container. podman already forwards the proxy env, so that needed nothing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>