-
Notifications
You must be signed in to change notification settings - Fork 924
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support integration test framework that brings up a new control plane #87
Comments
@pwittrock wrote somewhere else:
The goal is to deprecate |
I think it might be useful to think broader. If I work on nodes, wouldn't I need to test against these components too? Let's just say we should have composable testing components, that lets a kubernetes engineer, or even an engineer working on a kubernetes solution, test his software easily, reliably and quickly. |
Agreed, the next big step for this is helping folks test their CRDs, which would mean some way of loading the CRD and controller from the harness as well. |
This looks awesome. @hoegaarden and I would like to have a crack at it. We chatted with @pwittrock about it on a call, and have a good idea where to start. |
@totherme cool, since we can't assign to you now, assign myself as a placeholder : ) |
+1 |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
This has been done. It's at https://github.com/kubernetes-sigs/testing_frameworks |
Time commitment: 30-60 hours (assuming knowledge of Go and the Ginkgo test framework)
We need a way to write integration tests for kubectl and point it at a control plane (apiserver, controller-manager, etcd, scheduler) running locally.
As a kubectl developer, when I write an integration test for kubectl, there should be a ginkgo test framework that launches a new control plane, and provides a kubeconfig to the test both as a tmp file and as a datastructure.
Framework should take the control plane binaries as flags instead of compiling them from source.
See example of a test framework that brings up the control plane here.
Link to existing e2e tests
The text was updated successfully, but these errors were encountered: