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 filters
to the trigger CRD
#7879
Comments
/help |
@Cali0707: Please ensure the request meets the requirements listed here. If this request no longer meets these requirements, the label can be removed In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/assign erharjotsingh |
Hi @erharjotsingh what we are looking to do is map the golang types that I linked above for the SubscriptionsApi Filters into a |
Thanks @Cali0707 for clarifying. I am trying to look into it further. I will get back on this. Thanks! |
hello @Cali0707 Please help me understand if this understanding is correct and kindly help to identify what all new fields new to be mapped. Thanks! |
@erharjotsingh we need to add another eventing/config/core/resources/trigger.yaml Lines 120 to 127 in 884f0da
the eventing/pkg/apis/eventing/v1/trigger_types.go Lines 123 to 179 in 884f0da
For example (more details needs to be added for objects types): filters:
description: 'Filters is an experimental field that conforms to the CNCF CloudEvents Subscriptions API. It''s an array of filter expressions that evaluate to true or false. If any filter expression in the array evaluates to false, the event MUST NOT be sent to the Subscriber. If all the filter expressions in the array evaluate to true, the event MUST be attempted to be delivered. Absence of a filter or empty array implies a value of true. In the event of users specifying both Filter and Filters, then the latter will override the former. This will allow users to try out the effect of the new Filters field without compromising the existing attribute-based Filter and try it out on existing Trigger objects. '
type: array
items:
type: object
properties:
all:
description: 'All evaluates to true if all the nested expressions evaluate to true. It must contain at least one filter expression. '
type: array
items:
type: object
any:
description: 'Any evaluates to true if at least one of the nested expressions evaluates to true. It must contain at least one filter expression. '
type: array
items:
type: object
cesql:
description: 'CESQL is a CloudEvents SQL expression that will be evaluated to true or false against each CloudEvent. '
type: string
exact:
description: 'Exact evaluates to true if the values of the matching CloudEvents attributes MUST all exactly match with the associated value String specified (case-sensitive). The keys are the names of the CloudEvents attributes to be matched, and their values are the String values to use in the comparison. The attribute name and value specified in the filter express MUST NOT be empty strings. '
type: object
x-kubernetes-preserve-unknown-fields: true
not:
description: 'Not evaluates to true if the nested expression evaluates to false. '
type: object
prefix:
description: 'Prefix evaluates to true if the values of the matching CloudEvents attributes MUST all start with the associated value String specified (case sensitive). The keys are the names of the CloudEvents attributes to be matched, and their values are the String values to use in the comparison. The attribute name and value specified in the filter express MUST NOT be empty strings. '
type: object
x-kubernetes-preserve-unknown-fields: true
suffix:
description: 'Suffix evaluates to true if the values of the matching CloudEvents attributes MUST all end with the associated value String specified (case sensitive). The keys are the names of the CloudEvents attributes to be matched, and their values are the String values to use in the comparison. The attribute name and value specified in the filter express MUST NOT be empty strings. '
type: object
x-kubernetes-preserve-unknown-fields: true |
hello @pierDipi |
Problem
As trigger filters are an experimental feature, up until now they have not been included directly in the CRD as the API may have changed. However, with the feature relatively stable and in beta, we should start including the
filters
field in the CRD for triggers.Persona:
Which persona is this feature for?
Exit Criteria
The trigger CRD has the
filters
field included by default.Time Estimate (optional):
How many developer-days do you think this may take to resolve? 1
Additional context (optional)
The text was updated successfully, but these errors were encountered: