What challenge are you facing?

Suppose we have a Concourse resource, called product-resource, which knows how to download software packages. It does this by interacting with an API which can tell it about software releases.

The product-resource resource definition might look like:

resources:
- name: example-product
  type: product-resource
  source:
    product_slug: example-product
    product_version: 1\.6\..*

And it might be in the plan like this:

jobs:
- name: get-and-do-something-with-product
  plan:
  - get: example-product
    version: every
  - task: do-something-with-the-software
    file: tasks/something-doer/task.yml

So far so good. If I create the pipeline, then anything in the 1.6.x series for example-product will be downloaded and acted on.

Looking at the resource view in the UI, I see that it starts with the latest version of example-product and only that version:

product_version: "1.6.15"

But I have a problem: I want to do something to all the versions in the 1.6.x line. I know that version: every will handle half of this. I expect the other half is check-resource.

So I run fly -t exampleci check-resource --from "product_version:1.6.12".

When I return to the web GUI, I can see that the resource has indeed found previous versions:

product_version: "1.6.15"
product_version: "1.6.14"
product_version: "1.6.13"

But that's all it's done. Builds don't trigger with the as-yet-untried versions.

This remains the case no matter whether I create the resource prior to creating the job, or if I create them together.

Bug Report

What I expect to happen is that history is rewound to the first resource found and then progressively played forward.

Now, if I haven't set version: every, then the behaviour of only acting on version 1.6.15 is expected. But I specifically need to replay history from a known point in time.

• Concourse version: 3.3.4
• Deployment type: BOSH
• Infrastructure/IaaS: GCP