TriggerTemplate does not create PVC

[disposab1e]

Expected Behavior

PVC is created.

Actual Behavior

{"level":"error","logger":"eventlistener","caller":"sink/sink.go:153","msg":"couldn't create resource with group version kind \"/v1, Resource=persistentvolumeclaims\": resource /v1, Resource=persistentvolumeclaims not supported","knative.dev/controller":"eventlistener","/triggers-eventid":"lvgvl","/trigger":"pipeline-trigger","stacktrace":"github.com/tektoncd/triggers/pkg/sink.Sink.processTrigger\n\tgithub.com/tektoncd/triggers/pkg/sink/sink.go:153\ngithub.com/tektoncd/triggers/pkg/sink.Sink.HandleEvent.func1\n\tgithub.com/tektoncd/triggers/pkg/sink/sink.go:95"}

Steps to Reproduce the Problem

1. Create a TriggerTemplae with PVC.

....
 resourcetemplates:
 - apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: $(uid)
   spec:
     resources:
       requests:
         storage: 5Gi
     accessModes:
       - ReadWriteMany
 - apiVersion: tekton.dev/v1alpha1
   kind: PipelineRun
   metadata:
     generateName: pipeline-run-
     annotations:
       argocd.argoproj.io/compare-options: IgnoreExtraneous            
   spec:
     ....

2. Trigger TriggerTemplate.
3. View erros in EventListener.

Additional Info

From the docs: TriggerTemplates can create any Kubernetes resource(s)

[disposab1e]

I see: As on now, only Tekton resources can be defined within a TriggerTemplate.

As in Tekton Pipelines it's a good idea to make the docs more clear!

[ncskier]

Thanks for your feedback @disposab1e. I created a PullRequest (#477) to address your issue over the TriggerTemplate documentation. Please let me know if you think my PullRequest will adequately solve your issue for new users who read through the Triggers documentation.

[ncskier]

As a second note, @disposab1e, would you find it very helpful if Tekton Triggers was able to create Kubernetes resources other than Tekton resources? Are you unable to use Tekton Triggers without this feature?

[disposab1e]

@ncskier Yes I think this can be very helpful?

We use for GitOps in OpenShift 3.11/Kubernetes 1.14 with:

• Argo CD 1.4.2 (Operator)
• Tekton Pipeline (v0.10.1)
• Tekton Triggers (v0.3.1)
• SelaedSecrets (v0.9.6)

Actually we use a single EventListener, TriggerBinding and TriggerTemplate for all off our CI/CD Pipelines serving many differnet projects in many different namespaces. All of our custom Tekton Pileline/Trigger Kubernetes Resources are in a single namespace.

apiVersion: tekton.dev/v1alpha1
kind: EventListener
metadata:
  name: pipeline-el
  namespace: awesome-pipelines
spec:
  serviceAccountName: pipeline-sa
  triggers:
    - name: pipeline-trigger
      bindings:
        - name: pipeline-tb
      template:
        name: pipeline-tt
---
apiVersion: tekton.dev/v1alpha1
kind: TriggerBinding
metadata:
  name: pipeline-tb
  namespace: awesome-pipelines
spec:
  params:
  - name: gitRevision
    value: $(body.git.revision)
  - name: gitUrl
    value: $(body.git.url)
  - name: pipelineName
    value: $(body.pipeline.name)
  - name: params
    value: $(body.pipeline.params)
---
apiVersion: tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: pipeline-tt
  namespace: awesome-pipelines
spec:
  params:
  - name: pipelineName
    description: Pipeline Name (build, deploy, verify)    
 resourcetemplates:
  - apiVersion: tekton.dev/v1alpha1
    kind: PipelineRun
    metadata:
      generateName: pipeline-run-
    spec:
      serviceAccountName: pipeline-sa
      pipelineRef:
        name: pipeline-$(params.pipelineName)
      params:
      - name: uid
        value: $(uid)
      resources:
      - name: git-source
        resourceSpec:
          type: git
          params:
          - name: revision
            value: $(params.gitRevision)
          - name: url
            value: $(params.gitUrl)
      workspaces:
      - name: pipeline-workspace
        persistentVolumeClaim:
          claimName: `pipeline-workspace`
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pipeline-workspace
spec:
  resources:
    requests:
      storage: 5Gi
  accessModes:
    - ReadWriteMany

We share a single PVC (big enough) between all of our PipelineRuns. A PipelineRun is triggered through a Webhook/EventListener with JSON payload.

To share this PVC we use the $(uid) from TriggerTemplate and dynamically create a directory inside the PVC as a minimum of isolation :-)
So we simple create a directory $(uid) inside the PVC at start and remove it at the end of our Pipelines.
To be honest it's not a nice solution... but it's a GitOps solution!

The same problem exists after migrating PipelineResources to Tasks and workspaces.

So we would like to have a possibilty to dynamically create a PVC with the TriggerTemplate.

apiVersion: tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
 name: pipeline-tt
 namespace: awesome-pipelines
spec:
 params:
 - name: pipelineName
   description: Pipeline Name (build, deploy, verify)    
resourcetemplates:
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: $(uid)
  spec:
    resources:
      requests:
        storage: 0.2Gi
    accessModes:
      - ReadWriteMany
 - apiVersion: tekton.dev/v1alpha1
   kind: PipelineRun
   metadata:
     generateName: pipeline-run-
   spec:
     serviceAccountName: pipeline-sa
     pipelineRef:
       name: pipeline-$(params.pipelineName)
     workspaces:
     - name: pipeline-workspace
       persistentVolumeClaim:
         claimName: `pipeline-workspace`

What I really miss is Error Handling tektoncd/pipeline#1684 and Lifecycle Management tektoncd/pipeline#1460

I'm also aware of the Auto Workspaces discussion: tektoncd/pipeline#1986

I don't think this will break any design decissions but can be very helpfull in some dynamic scenarios.

[ncskier]

@disposab1e Thank you for elaborating on your use-case. If you have the time, could you please turn your last comment, with your use-case, into a new Triggers issue? We'll probably want to add a feature for removing the TriggerTemplate limitation of only creating Tekton resources. I think that it will be helpful to discuss this feature with the community in a new issue 👍

(I can create the issue if you don't have time, but the issue will probably be more accurate/effective coming from you)

[disposab1e]

@ncskier Pleasure! #482

[ncskier]

Thanks!