Inconsistency with how we use and parameterize a taskRef

[skaegi]

In a Pipeline and PipelineRun we reference params, resources.inputs, and resources.outputs. In a Task and TaskRun we reference the same variables as inputs.params, inputs.resources, outputs.resources. This is a bit confusing and inconsistent. If we want to make a change here we better get going quick...

If we were to make a change here (and recognizing that it would be breaking) I would just want to use params, inputs, and outputs. e.g. pull params up as a child of the Task spec and make inputs and outputs an array of PipelineResources.

For example...

---
# from a Pipeline or PipelineRun
spec:
  tasks:
  - name: pipeline-task-1
    taskRef:
      name: my-task
    params:
    - name: my-param
      value: xyzzy
    resources:
      inputs:
      - name: workspace
        resource: my-repo
      outputs:
      - name: image
        resource: my-image
---
# from a TaskRun
spec:
  taskRef:
    name: my-task
  inputs:
    params:
    - name: my-param
      value: xyzzy    
    resources:
    - name: workspace
      resourceRef:
        name: my-repo
  outputs:
    resources:
    - name: image
      resourceRef:
        name: my-image
---

[bobcatfish]

This has been bothering me for a while now 😭

It is doubly bad b/c I'm pretty sure I did it....

[dlorenc]

In a Pipeline and PipelineRun we reference params, resources.inputs, and resources.outputs. In a Task and TaskRun we reference the same variables as inputs.params, inputs.resources, outputs.resources. This is a bit confusing and inconsistent. If we want to make a change here we better get going quick...

I would also love to write params to disk somehow under /workspace/inputs/params for full consistency.

[vdemeester]

@dlorenc what would be the benefit to write them to disk instead of passing via environment variable ? And then we are back to variable substitation and all-as-environment variables discussion 👼 (https://docs.google.com/document/d/1h_3vSApIsuiwGkrqSiegi4NVaYG4oVzBquGAhIN6qGM/edit#heading=h.api53thmnjwo)

[dlorenc]

@dlorenc what would be the benefit to write them to disk instead of passing via environment variable ? And then we are back to variable substitation and all-as-environment variables discussion 👼

I meant in addition to that method.

If we ever want tasks to be able to output parameters, then files would probably make sense for that, and then this would be consistent.

[bobcatfish]

One way of doing this in a backwards compatible way is to do this via the mutating webhook.

[dlorenc]

@skaegi do you still want to pursue this or should we close it out?

[bobcatfish]

I think it's important @dlorenc !

After looking into it a bit more, I think we should wait to see how #1273 plays out since that may change the way params are specified (and is a chance to make Pipeline + Task specification of params + resources more similar).

[vdemeester]

/assign
This is related to #1526 and #1526, so I'll tackle this along the others 👼

[vdemeester]

As of today (#1651), Task yamls for v1alpha2 look like the following:

spec:
  params:
     # params here
  resources:
    inputs:
      # inputs resources here
    outputs:
      # outputs resource here

I feel that, to close this issue, TaskRun should follow the same ? @bobcatfish @skaegi wdyt ?

[bobcatfish]

I agree @vdemeester let's do the same for TaskRun!

[vdemeester]

Once #1725 is merged, we should be able to close this one. How it will be exposed is covered by #1526