e2e: Require explicit kubeconfig context and default to kind-only for safety

[camilamacedo86]

From @mandarjog (here: #5329 (review))

Following the request for e2e tests:

• additionally consider an option that defaults to operating on kind clusters only (can be overridden) and requires context to be passed in.
• Using the default context in kubeconfig is also dangerous as someone an inadvertently change the context while the test is running.

[camilamacedo86]

Thanks @mandarjog for raising this! Let me address both points from your original comment:
#5329 (review)

1) “defaults to operating on kind clusters only”

The scaffolded e2e tests already fail fast on non-Kind ✅

The e2e flow is effectively Kind-only because it performs a Kind-specific step up front:

By("loading the manager image on Kind")
err = utils.LoadImageToKindClusterWithName(managerImage)
ExpectWithOffset(1, err).NotTo(HaveOccurred(), "Failed to load the manager image into Kind")

If someone accidentally runs make test-e2e while their default kube context points to prod/staging, this step fails immediately with “kind cluster not found”, before we do cert-manager work or apply anything to the target cluster.

Example:

# Developer has production as default context
$ kubectl config current-context
production-us-east-1

$ make test-e2e
By("loading the manager image on Kind")...
❌ Error: kind cluster not found
# Tests stop here

Why we don’t hard-enforce “Kind detection”

We could try to “detect Kind” by inspecting the kube context name, but that’s not a reliable contract to enforce in a generic scaffold because users can create clusters with different names:

• kind create cluster -> context: kind-kind
• kind create cluster --name test -> context: kind-test
• kind create cluster --name foo -> context: kind-foo

So instead of relying on naming heuristics, the scaffold relies on the concrete Kind-only operation (image load), which naturally fails fast on non-Kind.

KIND_CLUSTER is already configurable

Users can control the Kind cluster name via KIND_CLUSTER:

# Default
$ make test-e2e

# Custom cluster name
$ KIND_CLUSTER=my-test make test-e2e

This is also reflected in the scaffolded Makefile (KIND_CLUSTER ?= -test-e2e).
See:

2) “requires context to be passed in”

What we can do: optional context locking (follow-up PR)

I agree there’s value in letting users explicitly pin the kube context when they want to. I implemented optional context locking via KUBE_CONTEXT in follow-up PR #5336:

#5336

With that in place, when KUBE_CONTEXT is set, all kubectl commands add --context <value>.

Usage examples:

# Default (unchanged)
$ make test-e2e

# Optional: lock to a specific context
$ KUBE_CONTEXT=kind-test make test-e2e

# Or directly with go test
$ KUBE_CONTEXT=kind-test go test -tags=e2e ./test/e2e/ -v -ginkgo.v

Why we shouldn’t require passing context

Making KUBE_CONTEXT mandatory would break the “batteries included” experience of the scaffold (make test-e2e should work out of the box), and it would also diverge from the kubectl/client-go convention where the default is current-context unless explicitly overridden.

Note that: it's standard behavior across the ecosystem. If someone has their default context pointing at production, any kubectl-based tool (helm, terraform, kubectl itself) can target prod unless explicitly pinned with --context.

# If developer has production as default:
$ kubectl config current-context
production-us-east-1

# ALL these run on production:
$ helm install myapp ./chart          # Deploys to production
$ terraform apply                     # Applies to production
$ kubectl apply -f manifest.yaml      # Applies to production
$ make test-e2e                       # ❌ FAILS at image load (not on Kind)

Also, the scaffold can’t know what context name to require because cluster naming varies across environments.

Summary

• The scaffold already behaves like “Kind-only by default” because it fails fast on the Kind image-load step when not on Kind.
• For users who want extra safety/explicitness, KUBE_CONTEXT provides optional context locking (PR ✨ (go/v4): Add optional kubectl context locking for e2e tests #5336).
• Moreover, KIND_CLUSTER can be used with e2e tests and is defined in the Makefile
• The code and targets are documented with the whole info to make end users aware of
• E2E tests are scaffolds with tag so cannot be executed accidentally with go test ./...
• Users can still customise the scaffold to fit their workflow, but the defaults aim to remain simple and broadly compatible.

Thanks again for the review and collaboration!