Questions about EventBinding

[vincent-pli]

@iancoffey
I saw the Getting start doc.
Firstly, I like the project, seems it's depends on Knative event-sources (Am I right?), so it could support all sources from Knative-sources, such as github, kafka .etc. that's great.

I still have some question need clarification, thanks

1. No event binding in EventBinding crd.
   I have not see any event binding, like things: ${event.foo}, just some environment variables: $GHREPO, I think this could come from the content of event.

2. The TektonListener , seems this crd will created by EventBinding? if not any event binding requirement, just trigger. Could TectonListener be created independent?

3. Based on the process diagram, seems the PipelineResource will be create by EventBinding.
   That's not make sense, at the time, the event still not emitted, so no event could binding to PipelineResource, am I right? so I'm little confuse here, do we just create a PipelineResource template or what?

Expect to your reply, thanks.

Additional Info

[iancoffey]

No event binding in EventBinding crd.
I have not see any event binding, like things: ${event.foo}, just some environment variables: $GHREPO, I think this could come from the content of event.

I agree, this is a super important part that is non-existent in this experiment so far. The reason is more about order of operations now - there will soon be a major refactor of the TektonListener. I wanted to see how that shakes out before trying to address the EventBinding event payload handling situation.

The TektonListener , seems this crd will created by EventBinding? if not any event binding requirement, just trigger. Could TectonListener be created independent?

Yes the TektonListener is intended to be used by itself, without any EventBinding, and will likely soon be more independent from EventBinding, with its own instructions.

...do we just create a PipelineResource template or what?

Its a good point - the PipelineResources could be used as templates and spawns/reaped per event, but then it would be the Listener managing them. I guess this also depends on the output of the TektonListener refactor somewhat...curious any thoughts you may have.

[ncskier]

Hi Ian, to follow up on your comment

Yes the TektonListener is intended to be used by itself, without any EventBinding, and will likely soon be more independent from EventBinding, with its own instructions.

What is the use case that you see for the TektonListener by itself without any EventBindings? I was under the impression that the point of these resources was to solve the problem of triggering PipelineRuns from Events.

[vincent-pli]

@ncskier
I think there is one case: the Pipeline stuff do not need anything from Event content but trigger.
like this: tektoncd/pipeline#836

@iancoffey
For the PipelineResource, I think there two approach:

1. Create it when Event received and delete it after PipelineRun complete.
2. Create PipelineResource template, that will be great if PipelineResource could support variable substitution, please check this:
   Variable substitution in PipelineResource definition pipeline#914

[iancoffey]

What is the use case that you see for the TektonListener by itself without any EventBindings? I was under the impression that the point of these resources was to solve the problem of triggering PipelineRuns from Events.

@ncskier The Listener project existed and was PRed before the EventBinding concept was added - and some of the design of each exists to avoid having their functionality overlap, so the listener can continue to be useful on its own. I think a lot of that spec and boundaries are bound to change in the short term
but regarding the existing experiment - the Listener experiment spec defines an event type and (eg CloudEvent) and an event (like com.github.push) to listen for and creates PipelineRuns when it gets the right ones. The EventBinding takes care of all the resource creation and plumbing values around, but that config/setup can be done manually as well. How best to make event data available (presumably to the PipelineRunSpec) is a great point, one I am forming opinions on, and something we should certainly discuss

[a-roberts]

Pretty sure this is another good one we can close right? Triggers is progressing great ❤️

Updated: closing due to inactivity