Repository navigation
ci: run buildx sandboxes on the host network - #560
Closed
brunomenezes wants to merge 1 commit into
Closed
brunomenezes wants to merge 1 commit into
brunomenezes wants to merge 1 commit into
Conversation
|
Contributor
Coverage Report
📁 File Coverage (20 files)
|
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.
Summary
Makes the
cliandreleaseworkflows run the Buildx builder and itsRUNsandboxes on the runner's network. Since 2026-10-12 some GitHub-hostedubuntu-24.04runners carry an egress-proxy experiment (actions/runner-images#14925). On those runners, DNS inside the nested BuildKit sandbox fails intermittently, and everycartesi buildin the integration tests dies inapt-get updatewithCould not resolve 'ports.ubuntu.com'. The identical commit passes on runners without the experiment. Nothing in the CLI or the test Dockerfiles changed.How it works
Today, apt's DNS query from a
RUNstep crosses three network layers and never touches the runner's resolver:With this change, both layers collapse into the runner's network namespace, and BuildKit hands the sandbox the host's
/etc/resolv.confunchanged:Changes
docker/setup-buildx-actionincli.yamlandrelease.yamlgainsdriver-opts: network=host, which runs the builder container on the host network, and--oci-worker-net=hostinbuildkitd-flags, which runs everyRUNstep in that same namespace.buildkitd-flagsrestates the action's two default entitlements (security.insecure,network.host), since setting the input replaces them.Notes
20261012.601(westus3) failed in the Test step, one on20261002.596(eastus) passed, same commit and workflow. The runner image also moved (20261004.327→20261012.334), but its release notes show only tool bumps, no Docker or kernel change.RUNsteps now share the runner's network, so a Dockerfile that binds a port during a build would bind it on the runner. None of the test Dockerfiles do. Build outputs are unaffected.20261012.601and the tests pass, the fix is confirmed; on20261002.596the run is green but inconclusive.