testkube icon indicating copy to clipboard operation
testkube copied to clipboard

Notification Controller for Flux to Testkube events

Open lreimer opened this issue 2 years ago • 4 comments

Is your feature request related to a problem? As a software developer, I would like to automatically run all integration, performance, security and acceptance tests whenever a microservice is deployed or updated on a Kubernetes cluster.

Describe the solution you'd like What we need is a specific adapter that recieves Flux events to translate these into Testkube events to run tests or test suites. Flux supports the definition of generic notifications on events. See https://fluxcd.io/docs/guides/notifications/#define-a-provider The tests to run could be annotated on the changed Kubernetes object level, via labels or annotations.

lreimer avatar Mar 31 '22 21:03 lreimer

blocked by #1706

exu avatar Jun 27 '22 08:06 exu

After some thought I came up with a different solution. Instead of direct support for the Flux2 notification API, we could simply listen for add or update events on pods, deployments, services, .... that are annotated in a certain way to then trigger the execution of tests and test suites.

I have implemented a simple PoC here https://github.com/lreimer/testkube-watch-controller This implementation is inspired by the KubeWatch project.

lreimer avatar Aug 05 '22 22:08 lreimer

After some thought I came up with a different solution. Instead of direct support for the Flux2 notification API, we could simply listen for add or update events on pods, deployments, services, .... that are annotated in a certain way to then trigger the execution of tests and test suites.

I have implemented a simple PoC here https://github.com/lreimer/testkube-watch-controller This implementation is inspired by the KubeWatch project.

Hi Ireimer, would this approach mean that you could use whatever CD/GitOps tooling you like? For me, a feature like this would take TestKube to the next level. As the current ArgoCD integration, for example, doesn't really offer much in terms of a GitOps continuous testing approach. As you have to still manually trigger the test execution.

rcooper85 avatar Aug 09 '22 12:08 rcooper85

Hi Ireimer, would this approach mean that you could use whatever CD/GitOps tooling you like? For me, a feature like this would take TestKube to the next level. As the current ArgoCD integration, for example, doesn't really offer much in terms of a GitOps continuous testing approach. As you have to still manually trigger the test execution.

Hey @rcooper85 , exactly. Since this approach solely relies on K8s change events, any CD/GitOps tool should work, no matter if you do a manual rollout using kubectl, use an external CD pipeline like Github actions, or a proper GitOps tool, all these eventually result in K8s events being triggered.

There still are some challenges that the current PoC implementation does not solve yet. For example, the deduplication of changes events, for example in case of a Deployment. Also, the implementation would need to allow for the change to stabilize, before the tests are triggered. Also any parameters required by the test and test suite execution should or must be part of the Testkube state, since passing these via labels or annotations is impossible or at least not practical.

lreimer avatar Aug 09 '22 13:08 lreimer

I think this issue is addressed by #2134.

lreimer avatar Oct 05 '22 22:10 lreimer