[FEAT PM] - E2E suite for providers

[abhijith-darshan]

Priority

(Medium) I'm annoyed but I'll live

User Story

The e2e suite should provide conformance coverage for each provider — exercising happy and fail paths in parallel, isolated from unit tests via build tags, with fuzzed resource names and full cleanup — so each release ships with a verifiable proof that the controllers behave as specified against a live cluster.

Description

The current test/e2e/ Ginkgo suite runs every provider scenario sequentially inside a single go test invocation and lacks build-tag separation, so unit-test runs pull e2e code into compilation and a failure in one provider blocks the rest. The suite also reuses fixed resource names across scenarios, which makes interleaved or repeated local runs flaky and leaves orphaned objects on the remote cluster when teardown fails. The bootstrap is also tied to a fixed two-cluster kind layout; the suite cannot reuse an existing Greenhouse environment or onboard a real downstream cluster.

A new e2e/ suite is needed that runs against a single kind cluster hosting Greenhouse and the Permission Manager controller, with the option to onboard additional clusters (kind or real) as downstream targets via the standard Greenhouse Cluster resource and kubeconfig Secret. The suite lives behind an e2e build tag (excluded from go test ./...), executes each provider in its own top-level Context running in parallel because the kubernetes and github providers do not share state, generates randomised resource names per spec, and tears down every resource it creates regardless of test outcome.

Acceptance Criteria

• New e2e/ folder at repo root; old test/e2e/ is deleted in the same change

• Every test file in e2e/ carries //go:build e2e so go test ./... and make test skip the suite; only go test -tags e2e ./e2e/... (or a dedicated make target) executes it

• Bootstrap creates one kind cluster running Greenhouse + Permission Manager; downstream targets are registered through the standard Greenhouse Cluster resource + kubeconfig Secret flow, so a real cluster's kubeconfig can be plugged in via environment variable without changing test code

• Each provider (kubernetes, github) runs inside its own top-level Ginkgo Context block ordered with Ordered, and the contexts are configured to run in parallel via --procs because the providers do not conflict on cluster state

• Each provider context covers at least one happy-path scenario (ASR applied, status reaches Ready=True, target resources observed on the downstream) and one fail-path scenario (e.g. invalid CCRN, missing ConnectorBinding, unmapped capability) asserting the expected InvalidConfig reason on status

• Resource names (ASR, ConnectorBinding, namespaces, RBAC objects, GitHub teams, etc.) are fuzzed per spec via a helper that returns a short random suffix; no hard-coded names that could collide across reruns

• Every resource created by a spec is removed in DeferCleanup (or equivalent) so a passing run leaves the cluster as it found it; teardown runs even when the spec fails

• Shared helpers (cluster onboarding, client construction, randomised name generation, common assertions) live in an e2e/shared/ package and are reused across provider contexts

• make e2e target wires the build tag, parallelism flags, and bootstrap so the suite runs locally with a single command against the kind cluster; the same target works unchanged when a real downstream kubeconfig is supplied via env var

Reference Issues

#2070

[github-actions]

Thanks for opening this issue! 🎉

A maintainer will triage it within 5 business days. You can learn more about our issue workflow in the Issue Lifecycle documentation.

In the meantime, please make sure you have provided:

• A clear problem statement
• Steps to reproduce (for bugs)
• Expected vs actual behavior

This helps us route your issue faster.