Feature: Allow Triggers to invoke other triggers after interceptor processing #945
Comments
jmcshane
added
the
kind/feature
|
Thanks for writing this up. So this looks like a solution to the problem discussed in #820 It's a problem that I've been thinking through a bit myself :)
Is the main reason you want this maintainability of the YAML configurations or some performance concerns (or both)? From going through the slack discussion, it seems to me that maintainability of the trigger configs was one big concern (if possible, could you share some of the trigger configs?) So, my initial thoughts are:
Overall, looks like a lot to discuss so before we jump into a solution. Let's discuss the use cases (maintainability, performance) and the tradeoffs (complexity of the Trigger type). I can add this to the agenda for next week's WG. In the meantime, we can keep discussing in this issue (and I'll try to spend some more time thinking through this problem!). Appreciate any feedback! |
|
Thanks for your feedback @dibyom. I'll definitely plan to join the WG on Wednesday. I'm trying to sanitize out my company specific information from the Trigger objects, but I'll share some examples before WG. One alternative I want to address is that idea of a "group" of triggers. I'm very willing to go with that approach, but the downside here is that you need to somehow select the bindings that tie to that trigger. For example, we're adding extensions on the event based on an API call as we are tracking the apps "onboarded" to our tekton platform. Then, these extensions allow a repository to get a number of different pipelines invoked based on different git events (PR, merge, tag, release, comment). With a group of triggers, we need to be able to conditionally select which ones in the group are valid for this event. This leads back to "how do you make that determination" and triggers already provides that answer: interceptors. A shareable interceptor chain across multiple triggers is an interesting alternative, but it still leads to an explosion of triggers that are processed on invocation (especially if that requires multiple external API calls). One of the challenges here is that trigger templates provision static k8s resources (specifically, workspace configuration is something we are trying to control with this logic). The proposed solution reduces this because you can reduce the filter steps to exactly the point that you know that this one specific trigger is valid. As we continue in the discussion, check out the changes I made to the API packages in #946. I don't mean to say its the "right" solution, but it gives a starting point of how this could be implemented. |
As described in tektoncd#945, this feature allows triggers to invoke other triggers by adding a trigger ref onto the Trigger object. Hidden triggers are created by setting the `tekton.dev/sink=hidden` label on the Trigger CRD object. Hidden triggers are not invoked in the main HandleFunc of the sink, but rather invoked when referenced in a trigger that has completed interceptor processing. Further discussion continues in tektoncd#945, but wanted to get something out here to demonstrate the approach.
As described in tektoncd#945, this feature allows triggers to invoke other triggers by adding a trigger ref onto the Trigger object. Hidden triggers are created by setting the `tekton.dev/sink=hidden` label on the Trigger CRD object. Hidden triggers are not invoked in the main HandleFunc of the sink, but rather invoked when referenced in a trigger that has completed interceptor processing. Further discussion continues in tektoncd#945, but wanted to get something out here to demonstrate the approach.
As described in tektoncd#945, this feature allows triggers to invoke other triggers by adding a trigger ref onto the Trigger object. Hidden triggers are created by setting the `tekton.dev/sink=hidden` label on the Trigger CRD object. Hidden triggers are not invoked in the main HandleFunc of the sink, but rather invoked when referenced in a trigger that has completed interceptor processing. Further discussion continues in tektoncd#945, but wanted to get something out here to demonstrate the approach.
As described in tektoncd#945, this feature allows triggers to invoke other triggers by adding a trigger ref onto the Trigger object. Hidden triggers are created by setting the `tekton.dev/sink=hidden` label on the Trigger CRD object. Hidden triggers are not invoked in the main HandleFunc of the sink, but rather invoked when referenced in a trigger that has completed interceptor processing. Nested triggers can also retrieve the extensions from the interceptor chain of parent triggers. This can be helpful in the future in case a set of triggers want to create a default set of extensions for trigger processing. Further discussion continues in tektoncd#945, but wanted to get something out here to demonstrate the approach.
As described in tektoncd#945, this feature allows triggers to invoke other triggers by adding a trigger ref onto the Trigger object. Hidden triggers are created by setting the `tekton.dev/sink=hidden` label on the Trigger CRD object. Hidden triggers are not invoked in the main HandleFunc of the sink, but rather invoked when referenced in a trigger that has completed interceptor processing. Nested triggers can also retrieve the extensions from the interceptor chain of parent triggers. This can be helpful in the future in case a set of triggers want to create a default set of extensions for trigger processing. We protect the nested triggers from an infinite loop of triggers by passing a custom extension down through the trigger nesting and tracking how deep in the nesting tree we are at that time. Further discussion continues in tektoncd#945, but wanted to get something out here to demonstrate the approach. Tracking nested trigger via extensions
As described in tektoncd#945, this feature allows triggers to invoke other triggers by adding a trigger ref onto the Trigger object. Hidden triggers are created by setting the `tekton.dev/sink=hidden` label on the Trigger CRD object. Hidden triggers are not invoked in the main HandleFunc of the sink, but rather invoked when referenced in a trigger that has completed interceptor processing. Nested triggers can also retrieve the extensions from the interceptor chain of parent triggers. This can be helpful in the future in case a set of triggers want to create a default set of extensions for trigger processing. We protect the nested triggers from an infinite loop of triggers by passing a custom extension down through the trigger nesting and tracking how deep in the nesting tree we are at that time. Further discussion continues in tektoncd#945, but wanted to get something out here to demonstrate the approach. As is assumed in the resolve trigger function, we assume that the nested trigger must be in the same namespace as the invoking trigger.
As described in tektoncd#945, this feature allows triggers to invoke other triggers by adding a trigger ref onto the Trigger object. Hidden triggers are created by setting the `tekton.dev/sink=hidden` label on the Trigger CRD object. Hidden triggers are not invoked in the main HandleFunc of the sink, but rather invoked when referenced in a trigger that has completed interceptor processing. Nested triggers can also retrieve the extensions from the interceptor chain of parent triggers. This can be helpful in the future in case a set of triggers want to create a default set of extensions for trigger processing. We protect the nested triggers from an infinite loop of triggers by passing a custom extension down through the trigger nesting and tracking how deep in the nesting tree we are at that time. Further discussion continues in tektoncd#945, but wanted to get something out here to demonstrate the approach. As is assumed in the resolve trigger function, we assume that the nested trigger must be in the same namespace as the invoking trigger.
As described in tektoncd#945, this feature allows triggers to invoke other triggers by adding a trigger ref onto the Trigger and EventListener objects. Hidden triggers are created by setting the `tekton.dev/sink=hidden` label on the Trigger CRD object. Hidden triggers are not invoked in the main HandleFunc of the sink, but rather invoked when referenced in a trigger that has completed interceptor processing. Nested triggers can also retrieve the extensions from the interceptor chain of parent triggers. This can be helpful in the future in case a set of triggers want to create a default set of extensions for trigger processing. We protect the nested triggers from an infinite loop of triggers by passing a custom extension down through the trigger nesting and tracking how deep in the nesting tree we are at that time. Further discussion continues in tektoncd#945, but wanted to get something out here to demonstrate the approach. As is assumed in the resolve trigger function, we assume that the nested trigger must be in the same namespace as the invoking trigger.
As described in tektoncd#945, this feature allows triggers to invoke other triggers by adding a trigger ref onto the Trigger and EventListener objects. Hidden triggers are created by setting the `tekton.dev/sink=hidden` label on the Trigger CRD object. Hidden triggers are not invoked in the main HandleFunc of the sink, but rather invoked when referenced in a trigger that has completed interceptor processing. Nested triggers can also retrieve the extensions from the interceptor chain of parent triggers. This can be helpful in the future in case a set of triggers want to create a default set of extensions for trigger processing. We protect the nested triggers from an infinite loop of triggers by passing a custom extension down through the trigger nesting and tracking how deep in the nesting tree we are at that time. Further discussion continues in tektoncd#945, but wanted to get something out here to demonstrate the approach. As is assumed in the resolve trigger function, we assume that the nested trigger must be in the same namespace as the invoking trigger.
As described in tektoncd#945, this feature allows triggers to invoke other triggers by adding a trigger ref onto the Trigger and EventListener objects. Hidden triggers are created by setting the `tekton.dev/sink=hidden` label on the Trigger CRD object. Hidden triggers are not invoked in the main HandleFunc of the sink, but rather invoked when referenced in a trigger that has completed interceptor processing. Nested triggers can also retrieve the extensions from the interceptor chain of parent triggers. This can be helpful in the future in case a set of triggers want to create a default set of extensions for trigger processing. We protect the nested triggers from an infinite loop of triggers by passing a custom extension down through the trigger nesting and tracking how deep in the nesting tree we are at that time. Further discussion continues in tektoncd#945, but wanted to get something out here to demonstrate the approach. As is assumed in the resolve trigger function, we assume that the nested trigger must be in the same namespace as the invoking trigger.
|
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
tekton-robot
added
the
lifecycle/stale
dibyom
removed
kind/feature
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. Addresses tektoncd#945
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. Addresses tektoncd#945
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. Addresses tektoncd#945
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. Addresses #945
|
Fixes as part of this PR #1232 |
Feature request
Triggers processed in the sink right now can currently only resolve to a single template and set of bindings. As outlined in #820, there is often a goal to do some initial interceptor processing before invoking additional triggers. In this implementation, a
Triggersfield would be added to the currentTriggerSpecthat would be a list of refs to Trigger objects accessible to the EventListener sink. After interceptor processing, the sub-triggers would be invoked alongside any existing binding/template pair set on the trigger.Some changes that would have to happen to make this work:
Use case
The use case is fairly well outlined in #820 as well. My team's use case is that we are passing additional metadata along with each repository and having a webhook add that metadata via a webhook extension. We want to run that webhook once for each invocation of the eventlistener, then separate processing into a set of subsequent triggers after that initial extension is processed.
The text was updated successfully, but these errors were encountered: