CEL expressions in TriggerBindings

[bigkevmcd]

Being able apply functions to the hook bodies in the trigger bindings might be useful.

Perhaps prefixing the expressions?

I think this can probably mostly be done with the CEL interceptor (with the the overlays functionality) so this might be an easy way around this.

apiVersion: tekton.dev/v1alpha1
kind: TriggerBinding
metadata:
  name: my-trigger-binding
spec:
  params:
  - name: shortsha
    value: cel:(truncate(body.pull_request.head.ref, 8))

[dibyom]

/kind feature
/area api

[ncskier]

Might need some discussion about replacing JSONPath or supporting both

[wlynch]

Previous discussion: #178 (comment)

[dibyom]

At the Feb 11 WG, we decided we can push this after the 0.3 milestone

[bitsofinfo]

would love this!

[tekton-robot]

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]

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.

[tekton-robot]

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.

[tekton-robot]

@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.

[dibyom]

/lifecycle frozen

[Fantaztig]

@dibyom I was just trying to find out why this isn't supported yet, do you maybe have some discussion that you could link in this issue? 😄
Since it's been frozen for almost 4 years now, it seems like it's not as easy as it seems!

[bigkevmcd]

@Fantaztig Do you have a specific use-case in mind?

I suspect most of this can be done with a CEL "overlays"?

[Fantaztig]

It's not really a big issue, more a cosmetic thing.
Currently we extract most of the webhook data we need inside the TriggerBinding e.g. via $(body.changes[0].ref.displayId).
Some info needs some light processing though, e.g. body.pullRequest.fromRef.displayId.split('/')[1], those we have inside the EventListener right now as overlays.

What I dislike a bit about that is that

• a) some of the overlays in the EventListener are quite redundant as they are always the same for the same TriggerBinding.
• b) the TriggerBinding has a mix of both expressions accessing data from the payload and those simply remapping the info returned by the EventListener which means I need to check two different files to know what data is actually loaded into which param.

I'm open to alternative approaches though, is the best practice to have all the value extraction inside the EventListener despite the redundancy? Or is there another way? 😃