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
Draft
ci: add an IPv6-only kind e2e job [DO NOT MERGE — needs #958 and #911]#939Yuan Gao (ygao-g) wants to merge 1 commit into
Yuan Gao (ygao-g) wants to merge 1 commit into
Conversation
Yuan Gao (ygao-g)
force-pushed
the
ci-kind-ipv6
branch
5 times, most recently
from
August 14, 2026 18:13
72285e4 to
68972e5
Compare
2 tasks
Yuan Gao (ygao-g)
force-pushed
the
ci-kind-ipv6
branch
from
August 17, 2026 18:11
68972e5 to
4363e8f
Compare
Yuan Gao (ygao-g)
force-pushed
the
ci-kind-ipv6
branch
from
August 19, 2026 01:23
4363e8f to
ef02488
Compare
Yuan Gao (ygao-g)
force-pushed
the
ci-kind-ipv6
branch
from
August 19, 2026 17:24
ef02488 to
748e841
Compare
Yuan Gao (ygao-g)
force-pushed
the
ci-kind-ipv6
branch
5 times, most recently
from
August 20, 2026 16:43
ba8d79e to
af37e8b
Compare
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.
Yuan Gao (ygao-g)
force-pushed
the
ci-kind-ipv6
branch
from
August 22, 2026 16:55
af37e8b to
498cd7f
Compare
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.
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-systeminstall, 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-testgate 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
kubectlon 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 aci/ipv6label on a pull request is the other. Could a maintainer create the label? The label trigger cannot fire without it.🤖 Generated with Claude Code