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
When a Task (say "task B") in a Pipeline gets a PipelineResource from another Task (say "task A"), this means that Task B wants to use a version of the PipelineResource which has been changed by the previous Task A (as described in #1076: "Resources in general should represent reconciliation between a system in the outside world and a filesystem injected into a Tekton Task.").
This means:
Task B doesn't actually want to use the original PipelineResource, Task B wants to use the changed PipelineResource
If another Task, e.g. Task C, also wanted to use the same PipelineResource, but not "from" Task A, it would want to use the original PipelineResource, not the new one
i.e. Using a PipelineResource as an output should create a new PipelineResource
Actual Behavior
As described in #1076 we create PVCs to hold PipelineResources when from is used (and even when it isn't, but that's another story...) and when a PipelineResource is an output, we copy the data from the local filesystem to the PVC, then use that data as the source for any downstream Tasks that need this PipelineResource as an input.
This means that fan-in behavior is actually undefined, e.g. in this scenario:
Say that pipeline-task-2-parallel-1 and pipeline-task-2-parallel-2 both used the same PipelineResource as an output (e.g. wrote the file "foo" to disk), and pipeline-task-3 used it as an input.
Which "foo" would pipeline-task-3 get? It's undefined.
Additional Info
We may want the Volumes (#1184) PipelineResource type to be an exception to this b/c folks (e.g. jenkins X) have use cases where they want to just pass data between Tasks without having to upload it somewhere in between. However this implies that fan-in should not be allowed for Tasks using Volumes.
The text was updated successfully, but these errors were encountered:
The proposal in that doc includes immutable PipelineResources. Closing this issue to reduce the number of issues we need to update with the same information.
Expected Behavior
When a Task (say "task B") in a Pipeline gets a PipelineResource from another Task (say "task A"), this means that Task B wants to use a version of the PipelineResource which has been changed by the previous Task A (as described in #1076: "Resources in general should represent reconciliation between a system in the outside world and a filesystem injected into a Tekton Task.").
This means:
i.e. Using a PipelineResource as an output should create a new PipelineResource
Actual Behavior
As described in #1076 we create PVCs to hold PipelineResources when
from
is used (and even when it isn't, but that's another story...) and when a PipelineResource is an output, we copy the data from the local filesystem to the PVC, then use that data as the source for any downstream Tasks that need this PipelineResource as an input.This means that fan-in behavior is actually undefined, e.g. in this scenario:
Say that
pipeline-task-2-parallel-1
andpipeline-task-2-parallel-2
both used the same PipelineResource as an output (e.g. wrote the file "foo" to disk), andpipeline-task-3
used it as an input.Which "foo" would
pipeline-task-3
get? It's undefined.Additional Info
We may want the Volumes (#1184) PipelineResource type to be an exception to this b/c folks (e.g. jenkins X) have use cases where they want to just pass data between Tasks without having to upload it somewhere in between. However this implies that fan-in should not be allowed for Tasks using Volumes.
The text was updated successfully, but these errors were encountered: