concourse: Resource versions not being passed

Bug Report

We recently noticed that resource versions are never passed from one task to the next for some pipelines. Given two jobs like this:

- name: job1
  - get: resource1
    trigger: true
- name: job2
  - get: resource1
    passed: [job1]
    trigger: true

The second job does not trigger when resource1 updates, and doesn’t find versions of resource1 when triggered manually. I haven’t been able to replicate this with a simple example pipeline, and I found that creating a new pipeline with exactly the same configuration as the broken pipeline works as expected, so I’m guessing this is related to something in the pipeline history. Has anybody else experienced this kind of issue, or have tips for debugging?

Concourse version: 3.1.1/3.2.0
Deployment type (BOSH/Docker/binary): BOSH
Infrastructure/IaaS: AWS
Did this used to work? Yes

cc @LinuxBozo @cnelson

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 1
Comments: 34 (22 by maintainers)

Most upvoted comments

Howdy all. The CF Release Integration team has two pipelines showing this bug as well. It’s new in the last few days.

We’re running Concourse 3.1.1 on GCP. @vito @chendrix, let me know what other information I can provide.

dsabeti on Jul 5, 2017

@chendrix @vito More updates on this. We’ve now seen Concourse fail to grab the correct version of the resource even when there are are no passed constraints:

We have this job which pulls in a certificate from a versioned s3 resource (master-bosh-root-cert):

Today when attempting to deploy it was grabbing an old version (SZD...), there are no passed constraints or anything else involved, this is the first job in a pipeline pulling a file from s3:

Examining the resource shows a newer version available (kaU...) but it’s not used:

Other pipelines that rely on this “same exact resource” (re: 3.0+ check container sharing) configuration were pulling the correct version. If I rename the resource to something else and refly the pipeline it grabbes the correct version. If I then rename the resource back to it’s original name, it reverts to grabbing the same (old, wrong) version.

It’s really concerning that we can’t trust concourse to be pulling in the correct versions. In this case it was a cert which being out of date caused a deploy to fail so we immediately noticed it, but it could have been a stemcell or other security update that wouldn’t break if it was out of date and we might not notice for a while – that’s a huge deal from a security and compliance perspective.

Any ideas on how to debug this?

cnelson on Jun 25, 2017