Skip to content

ci: add an IPv6-only kind e2e job [DO NOT MERGE — needs #958 and #911] - #939

Draft
Yuan Gao (ygao-g) wants to merge 1 commit into
agent-substrate:mainfrom
ygao-g:ci-kind-ipv6
Draft

ci: add an IPv6-only kind e2e job [DO NOT MERGE — needs #958 and #911]#939
Yuan Gao (ygao-g) wants to merge 1 commit into
agent-substrate:mainfrom
ygao-g:ci-kind-ipv6

Conversation

@ygao-g

@ygao-g Yuan Gao (ygao-g) commented Aug 13, 2026

Copy link
Copy Markdown
Collaborator

Part of #246. No IPv6 coverage exists anywhere in CI, so nothing catches a change that breaks IPv6-only, and the IPv6 work is a set of changes that do little apart. This job builds a single-stack v6 kind cluster, does a full --deploy-ate-system install, and runs the networking suite, where every test that can tell one address family from another lives — asserting the cluster really is single-stack before installing anything, so a green run cannot be vacuous. The branch is one workflow file and carries no copy of what it exercises: dispatch it with a list of pull requests and it merges them onto main in that order, and the stack lives only for the length of the run.

Not for merging yet — it needs #958 and #911 in first. Against main alone it fails closed: the IPv6-only CoreDNS fix in #958 and the atenet admin bind in #911 both have to be in before the install reaches anything, so until they land this is a standing red rather than a signal. After that it is mergeable as-is, and it stays out of the e2e-test gate either way, so it never blocks a pull request.

Single-stack IPv6 on kind still has rough edges, which is why this lane is opt-in and deliberately not on a schedule. A fresh IPv6-only cluster resolves nothing from a pod until CoreDNS is pointed at a reachable upstream (#958); the in-cluster registry address goes stale (#1049); and the kubeconfig repoint breaks kubectl on a native-Linux Docker host (#1099). Those are the things that have to close before this is dependable enough to run unattended — until then, dispatch is the way to get a result, and a ci/ipv6 label on a pull request is the other. Could a maintainer create the label? The label trigger cannot fire without it.

🤖 Generated with Claude Code

@ygao-g
Yuan Gao (ygao-g) force-pushed the ci-kind-ipv6 branch 5 times, most recently from 72285e4 to 68972e5 Compare August 14, 2026 18:13
@ygao-g Yuan Gao (ygao-g) changed the title ci: add a label-gated IPv6-only kind e2e job ci: add an IPv6-only kind e2e job [DO NOT MERGE — signal only] Aug 14, 2026
@ygao-g Yuan Gao (ygao-g) added the DO NOT MERGE This PR must not be merged yet. label Aug 19, 2026
@ygao-g
Yuan Gao (ygao-g) force-pushed the ci-kind-ipv6 branch 5 times, most recently from ba8d79e to af37e8b Compare August 20, 2026 16:43
@ygao-g Yuan Gao (ygao-g) changed the title ci: add an IPv6-only kind e2e job [DO NOT MERGE — signal only] ci: add an IPv6-only kind e2e job [DO NOT MERGE — needs #958 and #911] Aug 20, 2026
No IPv6 coverage exists anywhere in CI, so nothing catches a change that
works only because every address is IPv4. This builds a single-stack v6
kind cluster, installs, and runs the networking suite -- where every test
that can tell one address family from another lives -- asserting the
cluster really is single-stack first so a green run cannot be vacuous.

Opt-in, not a gate. Label a pull request ci/ipv6 for a run, or dispatch it
with a list of pull requests to merge onto main first. That second way is
what lets this carry the workflow file alone: the changes it exists to
exercise no longer have to ride along in the diff, and there is no branch
to keep rebased. The label still has to be created upstream. Part of agent-substrate#246.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

DO NOT MERGE This PR must not be merged yet.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant