enricobuehler 3213c1b61c ci(flatpak): resolve over TCP so the flathub bootstrap stops failing on tag pushes ...

The flathub remote-add has now burned its entire retry budget and failed the job on
three consecutive tag builds — v0.15.0, the v0.15.0 re-point, and v0.16.0 — each one
needing a manual re-run to land the bundle.

The cause was already root-caused here on 2026-07-11 (see the Tooling step's comment):
home-runner-1's Docker embedded resolver at 127.0.0.11 drops UDP lookups while the
shared multi-org fleet is saturated. Nothing retransmits a dropped datagram, so the
lookup simply times out. The fix then was to widen retry.sh to 10 attempts (~9 min),
which comfortably outlasts a main push's ~8-workflow fan-out — but a TAG push starts
13 workflows at once, and that burst now outlives the whole budget. Retrying harder
is chasing the symptom; the transport is the problem.

`options use-vc` moves resolution to TCP, where the kernel retransmits and a query
cannot be silently lost under load. Same resolver and search path — only the
transport changes — so internal names still resolve exactly as before. Deliberately
no additional nameservers: a public resolver in the list could answer an internal
name (git.unom.io) with NXDOMAIN. retry.sh stays as the backstop for real upstream
blips.

Applied non-fatally, because Docker bind-mounts /etc/resolv.conf and may present it
read-only: a DNS tuning that cannot be applied must not be the thing that fails a
release build. If the write is refused we warn and stay on UDP, i.e. exactly today's
behaviour.

Scoped to the flatpak workflow, where the failure is actually evidenced, rather than
applied fleet-wide on suspicion.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-20 08:33:34 +02:00

..

ISSUE_TEMPLATE

feat(security): finish Windows firewall Public opt-in wiring + vuln-disclosure + doc cleanup

2026-07-03 14:08:17 +00:00

workflows

ci(flatpak): resolve over TCP so the flathub bootstrap stops failing on tag pushes

2026-07-20 08:33:34 +02:00