triggers
triggers copied to clipboard
tektoncd
TriggerTemplateRun !?
TriggerTemplates are really important to us as we use them to lay down non Tekton resources like ConfigMaps and Secrets however we have been forced to write our own implementation because our eventing is totally different. In addition to event based triggering we support API based triggering and what I observed is that the payload looks remarkably like what I imagine a TriggerTemplateRun object would be if it existed. Maybe something like...
apiVersion: tekton.dev/v1alpha1
kind: TriggerTemplateRun
metadata:
name: mytemplaterun
spec:
templateRef:
name: mytemplate
params:
- name: revision
value: v0.32.0
- name: url
value: https://github.com/GoogleContainerTools/skaffold
What I'm wondering is if Triggers could directly expose the TriggerTemplateRun instead of hiding it inside. This would let us adopt the Triggers controller at least for the Templating piece.
Ah interesting idea! So you'd like a way to trigger the creation of the resources in the TriggerTemplate arbitrarily by providing the values you need 🤔
I think this is an interesting idea and I like the idea of making TriggerTemplates even more useful.
The plumbing repo is handling this problem (b/c they want to have crons that invoke TriggerTemplates) by curling the event listener URL with arbitrary data.
So one question for your use case @skaegi : the event listener is currently the only way to do validation of requests; do you want your TriggerTemplateRun instances to be validated (i.e. invoke an interceptor or just to get created exactly as decribed?
(Nitpick: I'm not sure if Run is the right word here? Tasks and Pipelines run because they have to start and complete, and while I guess that we are starting and completing something here, I feel like we are more "creating" something? I'm gonna create another issue to talk about naming)
No, I'm not looking for the interceptor to be involved at all. I'm just looking for a way to give a template some params and then make it so.
(re Nitpick: I just was picking on the word Run because it is kind of similar to a Pipeline/TaskRun)
For my own clarification - Is the primary reason to support these is to bundle params for multiple Resources specified in a template, instead of specifying each as a Pipeline/TaskRun? Are there any other advantages you see in specifying this as its own resource?
You may be interested in https://github.com/tektoncd/triggers/pull/226/files#diff-d5a0150984469b75717587a4812ee75aR187-R195 which separates out the behavior you're looking for into a library call rather than a resource.
Separately, this may have some impact/overlap on https://github.com/tektoncd/triggers/issues/189, which I'll try to capture in my proposal. Stay tuned!
We could potentially add a body field (with the above params) to EventListeners, where if detected, the pod would handle that singular "request" and then terminate. However, this would then complicate the status of EventListener (now they terminate?). Like @wlynch, perhaps the the library call above might suit you. @vdemeester any such plans the CLI to provide glue of this sort?
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Send feedback to tektoncd/plumbing.
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.
This is in the project roadmap https://github.com/tektoncd/triggers/blob/master/roadmap.md
/lifecycle frozen