Support setting default PipelineRun Workspace Binding

[fayfaychan]

Feature request

Tekton currently supports default TaskRun workspace binding: https://tekton.dev/docs/pipelines/workspaces/#setting-a-default-taskrun-workspace-binding

Can we do the same for PipelineRun for workspaces defined in the pipelinespec?

Use case

If a user has a pipeline as below, the organization can set a default workspace configuration and user don't need to specify the same on the Run.

# pipeline.yaml
metadata:
  name: pipeline
spec:
  workspaces:
    - name: pipeline-ws1
  tasks:
    - name: use-ws-again
      taskRef:
        name: commit # commit expects a workspace named "src"
      workspaces:
        - name: src
          workspace: pipeline-ws1

# pipelinerun.yaml
spec:
  pipelineRef:
    name: pipeline
  # workspaces:
  #  - name: unusedworkspace
  #    persistentVolumeClaim:
  #      claimName: mypvc

[dibyom]

Some earlier discussion here: #2595

[dibyom]

thoughts on adding a default workspaces for pipelineruns (controlled by a cluster operator @vdemeester @afrittoli @pritidesai?

it seems like there was interest in this from multiple users before (#2595) and we implemented something similar for taskruns but not pipelineruns. We did consider using workspace hinting, however that proposal has been in a proposed state for a long time and am not sure if we ever fully agreed on implementing it.

[vdemeester]

I think there is a lot to "uncover" for this. On top of my mind:

• What should be the behavior if there is multiple workspaces not bound ? Especially if the default workspace is a peristentVolumeClaim and not a template.
• What to do with optional workspaces ?
• What happens if there is only one workspace that is supposed to be "mounting" a pre-populated workspace (configmap, secret, or a PVC with some data already) ?

In essence, Kubernetes being relatively extensible, today this could be done independently of tektoncd/pipeline itself, as an external admission controller on PipelineRun and/or TaskRun. This would have the benefit of being more tailored to any specific situation on usage.

I think we should explore the "admission controller" way with documentation and possible experimental projects around this before trying to add anything in tektoncd/pipeline.