What would you like to be added
An e2e test that validates the quickstart flow works end-to-end: applying the quickstart manifests (Gateway, HTTPRoutes, XBackends, XAccessPolicies), deploying the MCP server, and verifying that tool calls are allowed/denied according to the policies.
This would catch regressions like the function collision bug (#272) which both broke the quickstart but weren't caught by existing e2e tests.
What should be tested
Using the quickstart policy manifests from site-src/guides/quickstart/policy/e2e.yaml:
initialize - allowed (base protocol method)tools/list - allowed (base protocol method)get-sum on local MCP backend - allowed (in inline allowlist)get-tiny-image on local MCP backend - allowed (in inline allowlist)echo on local MCP backend - denied (not in allowlist)
Optionally, with external auth quickstart manifests:
- Tool call to remote MCP backend with allowed repo - allowed
- Tool call to remote MCP backend with disallowed repo - denied
Options for running this
Option A: Add to existing e2e suite (tests/e2e/controller_test.go)
Add a new TestQuickstartE2E function that applies the quickstart manifests directly. The existing run-e2e.sh runner already calls setup_cluster_with_controller, so the cluster and controller are ready. The test would apply site-src/guides/quickstart/policy/e2e.yaml and the MCP server deployment, then run assertions using the same callTool/runKubectl helpers.
Pros: fits into existing CI (pull-kube-agentic-networking-e2e), reuses test infrastructure.
Cons: quickstart manifests hardcode quickstart-ns namespace which differs from the e2e namespace (e2e-test-ns).
Option A variant: Symlink or copy quickstart manifests into testdata
Instead of referencing site-src/ paths, copy the quickstart manifests into tests/e2e/testdata/ (or symlink). Avoids cross-directory dependencies but risks drift between the test copy and the real quickstart manifests.
Option B: New test suite that runs the quickstart script
A separate test or script (dev/ci/run-quickstart-smoke.sh) that actually runs run-quickstart.sh (without the agent/port-forward steps), then runs targeted tool call assertions against the gateway.
Pros: tests the actual quickstart script, catches script-level bugs (like #272).
Cons: needs a new Prow job, slower, harder to run assertions without the Go test framework.
Option C: Hybrid - Go test using quickstart manifests
A Go test in tests/e2e/ that applies the quickstart YAML files directly (not via the script) but uses the quickstart namespace and manifest paths. This validates the manifests are correct without testing the bash script itself.
Pros: catches manifest/policy regressions, runs in existing CI.
Cons: doesn't catch script bugs.
Options A or C seem most practical - they fit into existing CI and catch the most important regressions (policy/manifest correctness). Script-level bugs like #272 are rarer and can be caught by manual testing.
What would you like to be added
An e2e test that validates the quickstart flow works end-to-end: applying the quickstart manifests (Gateway, HTTPRoutes, XBackends, XAccessPolicies), deploying the MCP server, and verifying that tool calls are allowed/denied according to the policies.
This would catch regressions like the function collision bug (#272) which both broke the quickstart but weren't caught by existing e2e tests.
What should be tested
Using the quickstart policy manifests from
site-src/guides/quickstart/policy/e2e.yaml:initialize- allowed (base protocol method)tools/list- allowed (base protocol method)get-sumon local MCP backend - allowed (in inline allowlist)get-tiny-imageon local MCP backend - allowed (in inline allowlist)echoon local MCP backend - denied (not in allowlist)Optionally, with external auth quickstart manifests:
Options for running this
Option A: Add to existing e2e suite (
tests/e2e/controller_test.go)Add a new
TestQuickstartE2Efunction that applies the quickstart manifests directly. The existingrun-e2e.shrunner already callssetup_cluster_with_controller, so the cluster and controller are ready. The test would applysite-src/guides/quickstart/policy/e2e.yamland the MCP server deployment, then run assertions using the samecallTool/runKubectlhelpers.Pros: fits into existing CI (
pull-kube-agentic-networking-e2e), reuses test infrastructure.Cons: quickstart manifests hardcode
quickstart-nsnamespace which differs from the e2e namespace (e2e-test-ns).Option A variant: Symlink or copy quickstart manifests into testdata
Instead of referencing
site-src/paths, copy the quickstart manifests intotests/e2e/testdata/(or symlink). Avoids cross-directory dependencies but risks drift between the test copy and the real quickstart manifests.Option B: New test suite that runs the quickstart script
A separate test or script (
dev/ci/run-quickstart-smoke.sh) that actually runsrun-quickstart.sh(without the agent/port-forward steps), then runs targeted tool call assertions against the gateway.Pros: tests the actual quickstart script, catches script-level bugs (like #272).
Cons: needs a new Prow job, slower, harder to run assertions without the Go test framework.
Option C: Hybrid - Go test using quickstart manifests
A Go test in
tests/e2e/that applies the quickstart YAML files directly (not via the script) but uses the quickstart namespace and manifest paths. This validates the manifests are correct without testing the bash script itself.Pros: catches manifest/policy regressions, runs in existing CI.
Cons: doesn't catch script bugs.
Options A or C seem most practical - they fit into existing CI and catch the most important regressions (policy/manifest correctness). Script-level bugs like #272 are rarer and can be caught by manual testing.