You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would you like to be added:
A Common Expression Language (CEL) based assertion semantic.
The Common Expression Language (CEL) provides a standardized way to evaluate expressions, facilitating easier interoperability between different applications.
Currently, Kuttl lacks support for complex data manipulation in assertions. Here are a few examples where this limitation is apparent:
Testing whether a Deployment has created more than n Pods.
While Kuttl supports equality testing, conditional matching poses a challenge.
Slice assertion.
Kuttl's current method for handling slice comparison is somewhat obscure. Which become important especially when the order of elements in the slice is not fixed, which is common in Kubernetes (see Allow partial comparison of slices in asserts #76 (comment)).
I totally agree with the rationale. Kuttl definitely needs more powerful assertion capabilities.
Discussions on how to best express this never concluded.
I actually like how chainsaw solved this, some of the things there don't really look like YAML any more 😆
Your suggestion looks functional, even if somewhat different from how assertions are currently expressed in kuttl.
I wonder if you could write up a really short KEP do describe this and announce on the slack channel, to give others a chance to comment?
Personally I'd just maybe use id instead of identifier and put this into TestAssert rather than TestStep.
What would you like to be added:
A Common Expression Language (CEL) based assertion semantic.
Reference: https://github.com/google/cel-spec
Why is this needed:
Currently, Kuttl lacks support for complex data manipulation in assertions. Here are a few examples where this limitation is apparent:
n
Pods.These issues could be resolved by incorporating a CEL engine into Kuttl, allowing for expression evaluation and more flexible assertions.
How would this look like syntactically:
The text was updated successfully, but these errors were encountered: