chore(e2e-next): Test suites and label refactor

[adriankabala]

What issue type does this pull request address? (keep at least one, remove the others)
/kind test

What does this pull request do? Which issues does it resolve? (use resolves #<issue_number> if possible)
resolves #

Please provide a short message that should be published in the vcluster release notes
Fixed an issue where vcluster ...

What else do we need to know?

E2E Tests

Default Test Execution

The mandatory PR suite runs automatically. Only specify additional test suites below if needed.

Adding New Test Suites

When adding a new ginkgo test suite:

• Add labels to the test suite
• Update label-filter section below to execute the new test suite
• Verify test suite runs in CI/CD pipeline

Additional test suites

Additional test suite(s) that will be executed before the mandatory PR suite:

!non-default

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: da0f702ded

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[sowmyav27]

Question about labels.PR on shared specs

I noticed that labels.PR was added directly to shared specs like CoreDNSSpec(), PodSyncSpec(), PVCSyncSpec(), and AdmissionWebhookSpec(). These specs are registered in 5 suites: common-vcluster, rootless-vcluster, isolation-mode-vcluster, node-sync-vcluster, and scheduler-vcluster.

Because the pr label filter matches individual specs (not just the outer suite Describe), this means a normal PR run will now activate all 5 suites and provision 5 vClusters — previously only common-vcluster ran on PRs.

Was this intentional? Two scenarios:

1. Intentional (broader PR coverage): You want CoreDNS/PodSync/etc. to run against rootless, isolation, node-sync, and scheduler configs on every PR. If so, worth noting that NodeSyncSpec() and the two Scheduler*Spec() tests don't have labels.PR, so those clusters get provisioned but their unique tests are skipped — might want to add labels.PR to those too.

2. Unintended side effect: You wanted labels.PR on the specs for discoverability (know at a glance if a spec runs on PRs) but didn't intend to activate the other suites. If so, the fix would be to keep labels.PR only on the suite-level outer Describes and let specs inherit it.

[sowmyav27]

Non-blocking: Useful suite doc comments were removed

Several suite files had informative comments that were deleted alongside the stale // Matches: and // Run: lines. The stale ones were correct to remove, but these were still useful for discoverability:

• suite_metricsproxy_test.go: // PreSetup: installs metrics-server on host cluster via Helm
• suite_snapshot_test.go: // vCluster: SnapshotVCluster (CSI hostpath driver + snapshot CRDs)
• suite_servicesync_test.go: // vCluster: ServiceSyncVCluster (replicateServices config)
• suite_kubeletproxy_test.go: // vCluster: KubeletProxyVCluster (kubelet proxy with restricted subpaths)
• suite_e2e_nondefault_test.go: explanation of why it's separated from the PR suite

Without these, a new engineer has to read the cluster Go file + YAML to understand what a suite needs — which is the exact pain point from the Linear doc (item #2).

Consider preserving at least the // vCluster: and // PreSetup: lines, or replacing them with something like:

// Uses SnapshotVCluster — requires CSI hostpath driver PreSetup.

[adriankabala]

Question about labels.PR on shared specs

@sowmyav27: This is intentional. I deliberately moved labels.PR onto individual specs so that critical regression tests (CoreDNS, PodSync, Webhook, etc.) run against ALL vCluster configurations on every PR - not just common-vcluster. The additional vClusters (isolation, rootless, scheduler, node-sync) are provisioned concurrently and the entire e2e-next suite finishes in few min, which is significantly faster than the unit test suite. The broader coverage is worth the marginal cost. If we decide in the feature that is too long, it's super easy to change it.

[adriankabala]

Non-blocking: Useful suite doc comments were removed

Several suite files had informative comments that were deleted alongside the stale // Matches: and // Run: lines. The stale ones were correct to remove, but these were still useful for discoverability:

• suite_metricsproxy_test.go: // PreSetup: installs metrics-server on host cluster via Helm
• suite_snapshot_test.go: // vCluster: SnapshotVCluster (CSI hostpath driver + snapshot CRDs)
• suite_servicesync_test.go: // vCluster: ServiceSyncVCluster (replicateServices config)
• suite_kubeletproxy_test.go: // vCluster: KubeletProxyVCluster (kubelet proxy with restricted subpaths)
• suite_e2e_nondefault_test.go: explanation of why it's separated from the PR suite

Without these, a new engineer has to read the cluster Go file + YAML to understand what a suite needs — which is the exact pain point from the Linear doc (item #2).

Consider preserving at least the // vCluster: and // PreSetup: lines, or replacing them with something like:

// Uses SnapshotVCluster — requires CSI hostpath driver PreSetup.

Re: Removed suite doc comments:

Fair point - will restore the // vCluster: and // PreSetup: lines in a follow-up PR to keep this large change mergeable without re-review. Already tracked.