-
Notifications
You must be signed in to change notification settings - Fork 86
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
Add ability to match/assert fields on regex values #262
Comments
I would also like to see this implemented - even if my use case is a bit simpler. As described on Slack, my wish is to be able to assert that a field is present, but with no asserts on the field value. We built an operator on top of cert-manager, and as part of our e2e testing, we would like to assert that the certificate Secret contains the expected fields. But we can ofc not include any asserts on the fields - as the fields in question are transient: private keys, certificate chains, keystores etc. I am not sure how this feature could be implemented - since a field may have any value. One idea I have, is to follow the ytt approach, and express these kinds of asserts with "magic comments" as field values - in the test step asserts. This might look like this: ---
kind: Secret
apiVersion: v1
metadata:
name: my-certificate
data:
tls.crt: #@ regexp('^(?!\s*$).+')
type: kubernetes.io/tls @alenkacz WDYT? |
Second this, right now you cant asses a configmap value if some of it is autogenerated |
any updates here ? |
What would you like to be added:
I would like the ability to partially match fields of the resources in the asserter using something akin to a regex.
This is predominantly for integration/production test scenarios where you are not in complete control of the set values. But understand the range they should operate within.
Why is this needed:
The ability to do this will allow us to validate api-resource fields such as; resource limits, image tags, custom annotations and other fields that do not require discrete values to be valid for a test pass.
The text was updated successfully, but these errors were encountered: