Summary

With EnableCachedtreamedVolumes turning on, if get step finds a resource cache it's gonna fetch, then it will not do anything, just returned the found volume.

Say, a following task needs the get step as an input. If container placement strategy is volume-locality, then the task will be placed on the worker where the resource cache volume locates, which is bad, if the resource cache is widely used by many pipelines, because it will end up:

• All containers the need the resource as input will go to the same worker
• The resource volume will get no chance to be streamed to other workers, thus no way to sharing loads across workers.

Let's think about if EnableCachedtreamedVolumes off. Then the get should go to a fewest-build-container worker (#8061), then the task should go to the same worker per volume-locality.

Thus, when EnableCachedtreamedVolumes is on, as get does nothing, the task should go to a fewest-build-container worker, then stream the input volume from source worker. This is still more performant, because streaming a volume between workers should anyway cheaper than running a real get step. But for those common resource caches, which are shared by a lot of pipelines, once they are warmed up on most of workers, then build should run much faster.

Steps to reproduce

Expected results

Actual results

Additional context

Triaging info

• Concourse version: 7.6.0
• Browser (if applicable):
• Did this used to work?