You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently a Task matching pipelineTaskName specified as part of taskRunSpecs must exist in the Pipeline (although no explicitly documented), otherwise the PipelineRun will fail:
However in some cases, similar to those described in #2513 and #6856, it's useful for this to be permitted, as unused parameters and workspaces are today. Changing the default behaviour would be non-breaking (although possibly slightly surprising if people were relying on the behaviour). Alternatively, an extra boolean field optional could be added (similar to mounting optional Secrets as volumes), defaulted to false. Maybe this behaviour should be extended to workspaces and parameters too, so users can choose the behaviour?
Imagine you have a system creating PipelineRuns automatically, and each PipelineRun uses a different Pipeline which has a different set of parameters. The system has a number of parameters it knows how to provide, e.g. the service account and url of a bucket the Pipelines can push to (but not all Pipelines need to push to a bucket).
It would be very convenient if the system creating the PipelineRuns could provide all the parameters it has available to all PipelineRuns, and the Pipelines could use the ones they need and ignore the rest.
The text was updated successfully, but these errors were encountered:
Feature request
Currently a Task matching
pipelineTaskName
specified as part oftaskRunSpecs
must exist in the Pipeline (although no explicitly documented), otherwise the PipelineRun will fail:However in some cases, similar to those described in #2513 and #6856, it's useful for this to be permitted, as unused parameters and workspaces are today. Changing the default behaviour would be non-breaking (although possibly slightly surprising if people were relying on the behaviour). Alternatively, an extra boolean field
optional
could be added (similar to mounting optional Secrets as volumes), defaulted tofalse
. Maybe this behaviour should be extended to workspaces and parameters too, so users can choose the behaviour?Use case
Quoting #2513 as a similar use case:
The text was updated successfully, but these errors were encountered: