-
Notifications
You must be signed in to change notification settings - Fork 425
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 implementation for trigger groups #1052
Initial implementation for trigger groups #1052
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
5232a70
to
0d14397
Compare
The following is the coverage report on the affected files.
|
0d14397
to
786b15b
Compare
The following is the coverage report on the affected files.
|
786b15b
to
c317287
Compare
The following is the coverage report on the affected files.
|
c317287
to
47a1463
Compare
The following is the coverage report on the affected files.
|
47a1463
to
a418ffc
Compare
The following is the coverage report on the affected files.
|
a418ffc
to
f886d40
Compare
The following is the coverage report on the affected files.
|
@dibyom @afrittoli @wlynch this implementation is now ready in line with our discussion for TEP-0053. I reduced the changes that are a part of this PR to the absolute simplest possible, including maintaining the response code validation. The key reason I kept the response codes in here for now is because of the huge test surface that depends on this response code and expects the HTTP function to block until all resources are created. I think it makes sense to open a separate issue to track discussion on how we manage the HTTP status code. For now, this PR is ready from a code perspective. I think what we need to finish it are:
Please let me know if there is anything else you would like to see in this PR. |
Sounds good. We can tackle that separately as part of #931 |
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.
Haven't gone through all of the code yet. But yes, docs and examples would be the two remaining things.
Also, we should update the release notes section of the PR to something a bit more descriptive -- (Adds a way to group common interceptors across multiple triggers ...)
trItems, err := r.selectTriggers(el.Spec.NamespaceSelector, el.Spec.LabelSelector) | ||
if err != nil { | ||
r.Logger.Errorf("Unable to select configured triggers: %s", err) | ||
response.WriteHeader(http.StatusInternalServerError) |
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.
Should we return some info in the HTTP response as well?
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.
What info are you considering here to return besides the downstream error message?
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.
I was thinking something along the lines of a generic error message (like the unable to select configured triggers) along with the usual debugging pointers (eventID, eventListenerUID) so that its easy to look for in the logs. What do you think?
f886d40
to
bebe3a2
Compare
1d36627
to
bde9e40
Compare
/test pull-tekton-triggers-go-coverage |
The following is the coverage report on the affected files.
|
This feature allows an operator to specify a set of interceptors that will be executed before a group of triggers are selected and executed. This allows common data to be passed from interceptor execution down to multiple triggers to solve a set of common use cases across multiple Triggers. This feature is enabled for now inline in the EventListener spec, but in the future may be enabled only in alpha once the feature gates proposal is implemented within this project.
bde9e40
to
18f81b9
Compare
The following is the coverage report on the affected files.
|
/test pull-tekton-triggers-integration-tests |
@jmcshane: PR needs rebase. 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. |
PR handled as part of this #1232 |
Changes
Initial demo of using trigger groups to process eventlistener requests
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Release Notes