-
Notifications
You must be signed in to change notification settings - Fork 137
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
Initial version of CEL resource expressions. #928
Changes from all commits
f3ee705
d6aae5d
ba71388
a6d0852
be66d3c
b1c68b3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -63,10 +63,22 @@ type ReceiverSpec struct { | |
// +optional | ||
Events []string `json:"events,omitempty"` | ||
|
||
// TODO: Validate one or other (or both?) | ||
|
||
// A list of resources to be notified about changes. | ||
// +required | ||
Resources []CrossNamespaceObjectReference `json:"resources"` | ||
|
||
// ResourceExpressions is a list of CEL expressions that will be parsed to | ||
// determine resources to be notified about changes. | ||
// The expressions must evaluate to CEL values that contain the keys "name", | ||
// "kind", "apiVersion" and optionally "namespace". | ||
// These values will be parsed to CrossNamespaceObjectReferences. | ||
// e.g. {"name": "test-resource-1", "kind": "Receiver", "apiVersion": | ||
// "notification.toolkit.fluxcd.io/v1"}. | ||
// +optional | ||
ResourceExpressions []string `json:"resourceExpressions,omitempty"` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this should be named There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @stefanprodan The last test is borked because of a bug in controller-runtime which I've fixed, but is yet to be released If I understand what you're saying here, you would have This wouldn't be dynamic tho', it's not clear how it would solve the problem outlined in #491? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Precisely, that's exactly what we discussed in the dev meeting today! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Our reasoning is security, this style forces a more secure stance, the user always have to the declare which resources can be reconciled by the Receiver. They may end up with a long list of resources but at least it will always be clear from the Receiver object which Flux objects can be reconciled from that Receiver. |
||
|
||
// SecretRef specifies the Secret containing the token used | ||
// to validate the payload authenticity. | ||
// +required | ||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will need to be addressed, because you could have
.spec.resourceExpressions
or.spec.resources
(or both).