Is your feature request related to a problem? Please describe.
TWC has strong unit tests and envtest coverage, but nothing builds the controller, deploys it to a real cluster, and verifies it starts correctly under different configurations. This would help us catch configuration-level regressions automatically like the namespace-scoped ClusterConnection watch bug and the webhook cert Secret issue before they ship.
Describe the solution you'd like
A GitHub Actions workflow that builds the controller, deploys it to a Kind cluster with a matrix of Helm value configurations, and verifies it starts and works correctly.
Initial modes:
- baseline default: does TWC start? Verifies controller pods reach Running state
- namespace-scoped (restrictWatchNamespaces) verifies no error-level log entries
- byo-cert (certmanager.enabled=false) - Webhook accepts a test WorkerDeployment
The matrix pattern makes it easy to expand adding a new configuration is one simple entry. Future modes could include webhook.enabled=true, ClusterConnection usage, and custom certSecretName and more.
Additional context
Initial PR: #582
This came from a conversation with Eric about improving test infrastructure. The idea: every time we discover a new customer deployment configuration, we add it to the matrix. The tests catch regressions automatically instead of us relying on developers to remember to test each mode manually.
Is your feature request related to a problem? Please describe.
TWC has strong unit tests and envtest coverage, but nothing builds the controller, deploys it to a real cluster, and verifies it starts correctly under different configurations. This would help us catch configuration-level regressions automatically like the namespace-scoped ClusterConnection watch bug and the webhook cert Secret issue before they ship.
Describe the solution you'd like
A GitHub Actions workflow that builds the controller, deploys it to a Kind cluster with a matrix of Helm value configurations, and verifies it starts and works correctly.
Initial modes:
The matrix pattern makes it easy to expand adding a new configuration is one simple entry. Future modes could include webhook.enabled=true, ClusterConnection usage, and custom certSecretName and more.
Additional context
Initial PR: #582
This came from a conversation with Eric about improving test infrastructure. The idea: every time we discover a new customer deployment configuration, we add it to the matrix. The tests catch regressions automatically instead of us relying on developers to remember to test each mode manually.