Pipeline: params should support valueFrom

[skaegi]

All params value fields (e.g. pipelinerun, taskrun, pipelineresource) should support valueFrom similar to container env support -- see https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#envvar-v1-core and https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#envvarsource-v1-core

To start with we should support configMapKeyRef and secretKeyRef to avoid having to add extra fields like secrets to some of our PipelineResources and to let us parameterize PipelineResources from a PipelineRun.

[bobcatfish]

Sounds reasonable to me! @skaegi any chance you could provide an example of what this syntax would look like?

[skaegi]

Yes and I'm also signing up for doing this.

[skaegi]

/assign

[fraenkel]

I started to look at this closer. The question to answer is how the data should be reflected back.
If one uses a Value, its just as its done today.

1. If we support a valueFrom, should it be an envVar or volume?
2. We can't verify the type unless we pull the value which seems odd.
3. The current Secrets can be deprecated and replaced with Secrets via valueFrom hence the question above regarding env vars vs volumes.
4. I am also assuming we wouldn't carry over the optional behavior and just fail if set.

[skaegi]

Ha! @fraenkel !!!
I'm totally not answering your question but...
We might also want to figure out how to support "fieldref" https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#envvarsource-v1-core

I've had a couple of cases where I wanted the metadata.name to be injected via param

[skaegi]

I think in retrospect this might be a mis-feature. I've yet to have a case where I can't get at the data I need every bit as cleanly in an individual step using env or by 'volume/volumeMount' and a param for reference name.

[skaegi]

Ok. So my statement above still holds so closing.