Provide a mechanism to more easily access the "event" in a workspace in pipelines

[skaegi]

We run a slightly forked implementation of triggers that allows creation of the standard tekton resources as well as "configmaps". The "main" reason we need configmaps is because teams invariably want to package up the event (head and body). Typically done like so...

apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: event-listener
spec:
  triggers:
    - bindings:
        - name: header
          value: $(header)
        - name: body
          value: $(body)
      template:
        ref: trigger-template
---
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: trigger-template
spec:
  params:
    - name: header
    - name: body
  resourcetemplates:
    - apiVersion: v1
      kind: ConfigMap
      metadata:
        name: event-$(uid)
      data:
        header: $(tt.params.header)
        body: $(tt.params.body)
    - apiVersion: tekton.dev/v1beta1
      kind: PipelineRun
      metadata:
        generateName: pipelinerun-
      spec:
        pipelineRef:
          name: pipeline
        workspaces:
          - name: event
            configmap:
              name: event-$(uid)

This pattern is incredibly common -- near 100% of our pipelines use some variant of populating a workspace with the "event". Is there something we could do to make this somehow much easier and let us stop using a triggers "fork".

[savitaashture]

Hey @skaegi It would be helpful if you provide the usecase of this request

[anasinnyk]

I have some use-case for that. We deploy our trigger by GitOps and we want to have a more declarative way. We want to build our container image by KPack. We expect to catch GitHub PR webhook and create KPack manifest without any pipeline in the cluster. It will be really helpful if trigger support different kubernets resources.

[skaegi]

We have many users coming from different CIs that allowed users to write scripts against the event payload content for things like conditional logic and also for audit purposes. By moving the event into a well-known pipeline workspace name teams could access and parse the event payload themselves in their Tasks which in many cases is more flexible than doing this with bindings and having to add a ton of parameterization .

[tekton-robot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. 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 with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[dibyom]

I think we should allow creating configmaps. For the specific use case of passing trigger data to pipelineruns, we also have a TEP which could provide an alternative implementation: https://github.com/tektoncd/community/pull/1087