Proposal: Typed Values for TriggerBindings

[dibyom]

Current Behavior

Currently, TriggerBindings are a lot like Params in pipelines i.e. they have a name and a value field. The value field can either contain an expression - GJson/JSONPath which are wrapped in $() or it can be static string i.e. not wrapped in $().

spec:
  params:
  - name: gitrevision
    value: "$(body.head_commit.id)"
  - name: docker-registry
    value: "gcr.io/my-docker"

Proposal

Instead of reusing the same value filed and using $() to differentiate between expressions and strings we could use separate fields instead. This will allow us to get rid of the enclosing $() in front of the expressions
e.g.

spec:
  params:

  - name: gitrevision
    jsonPath: body.head_commit.id

  - name: docker-registry
    string: "gcr.io/my-docker"

Another alternative would be to get rid of the top level params as well:

spec:
  jsonPath:
  - name: gitrevision
    value: body.head_commit.id
  string:
  - name: docker-registry
    value: "gcr.io/my-docker"

cc @wlynch

[ncskier]

Neat idea! However, one thing to note is that this will restrict users so they can no longer mix static & json values:

• "my-static-string-$(body.path.to.a)"
• "$(body.path.to.a)-$(body.path.to.b)"

Here's an example TriggerBinding that my team uses that mixes static strings and json values (source here):

  - name: docker-tag
    value: $(body.repository.name):$(body.head_commit.id)

With this issue's proposed change, it would be easy to "fix" the TriggerBinding by passing the json values as separate params and joining them together in the TriggerTemplate. However, it's worth thinking about whether this will cost us flexibility and readability of the TriggerBindings + TriggerTemplates.

[dibyom]

Yeah, I noticed some of the tests had that but none of the examples so I wasn't sure if anyone was using the concat behavior in Bindings.

I don't have too strong of a feeling about this but having strong types does allow some nicer separation i.e. all of the string/template concatenation happens only in the templates and not in the binding. Though this will be a breaking change and can make the templates a bit more verbose.

[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]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

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 with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

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