-
Notifications
You must be signed in to change notification settings - Fork 1.2k
✨ introduce LabelChangedPredicate to trigger event on label change #1315
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
✨ introduce LabelChangedPredicate to trigger event on label change #1315
Conversation
Signed-off-by: Bruce Ma <[email protected]>
// This will be helpful when object's labels is carrying some extra specification information beyond object's spec, | ||
// and the controller will be triggered if any valid spec change (not only in spec, but also in labels) happens. | ||
type LabelChangedPredicate struct { | ||
Funcs |
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.
Can you use Funcs.UpdateFunc
rather than overwriting it?
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.
Sorry, maybe I didn't catch your point, I'm just doing the same way like ResourceVersionChangedPredicate and GenerationChangedPredicate, overriding the Update
method and inherit the others.
If we want to assign Funcs.UpdateFunc
, another constructing function will be introduced for this, and I think maybe it's not easy for using.
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.
Ah that's how you came up with it. From a user perspective it is just calling a constructor rather than using a type :)
The reason I think it's slightly better is that it might be confusing to have an embedded UpdateFunc
described as being called for Update events that does not actually get called for Update events :)
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.
:) Got your point, but your suggestion is keeping same as the other predicates or change all the predicates to a new way (use a constructor instead of stating a type), but I think the second way maybe a break change for some "legacy" users.
Or maybe we could just use the constructing way for the new LabelChangedPredicate
?
// This will be helpful when object's labels is carrying some extra specification information beyond object's spec, | ||
// and the controller will be triggered if any valid spec change (not only in spec, but also in labels) happens. | ||
type LabelChangedPredicate struct { | ||
Funcs |
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.
Ah that's how you came up with it. From a user perspective it is just calling a constructor rather than using a type :)
The reason I think it's slightly better is that it might be confusing to have an embedded UpdateFunc
described as being called for Update events that does not actually get called for Update events :)
pkg/predicate/predicate_test.go
Outdated
@@ -14,6 +14,7 @@ See the License for the specific language governing permissions and | |||
limitations under the License. | |||
*/ | |||
|
|||
//nolint:dupl |
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.
Why is this needed? Can we add an explanation comment for posterity and set it on a more granular level than on the whole package?
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.
comments is added and level is set to single function from whole package
9a1406d
to
4b527ac
Compare
Signed-off-by: Bruce Ma <[email protected]>
4b527ac
to
52c9e6f
Compare
/retest |
friendly ping @alvaroaleman , could you help to promote this PR? I think all comments have been addressed. |
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.
/label tide/merge-method-squash
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alvaroaleman, mars1024 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
…ubernetes-sigs#1315) * introduce LabelChangedPredicate to trigger event on label change Signed-off-by: Bruce Ma <[email protected]> * disable duplication linter on predicate tests Signed-off-by: Bruce Ma <[email protected]>
Signed-off-by: Bruce Ma [email protected]
This is a non-breaking feature ✨ .
Just as the title, a
LabelChangedPredicate
is introduced to trigger event on label change, if some extra specification information is carried through object's label, this predicate function will be useful.