Skip to content
No description, website, or topics provided.
Branch: master
Clone or download


Emits a YAML file listing versions of all resources for a given Concourse build.


  • For Concourse >= v5, use Stopver tag 2.0.0
  • For Concourse <= v4, use Stopver tag 1.1.0
$ export ATC_BEARER_TOKEN=foo
$ stopover team-name pipeline job build-number

Resource Versions File

stopover outputs a file of the following format:

  ref: fce993c58725102a01d9376714e386f7bb011e2f
  path: elastic-runtime/1/cf-1.11.16.pivotal
  random: "19401"
  path: mysql/1/p-mysql-1.10.5.pivotal

Using stopover to pin Resource Versions

You can automatically pin Concourse pipelines to specific versions of resources by using a file created bystopover. This allows you to re-use the exact same pipeline YAML for different environments. We use this pattern for pipelines that deploy Cloud Foundry.

If you put this to a resource, then other pipelines can be triggered by changes to this version file. These pipelines can then call fly set-pipeline on themselves or others, providing a load-vars-from flag pointing to the resource versions file. If the pipelines being set have their version blocks parameterised using Concourse's newer (()) syntax, then this will result in the pipeline only being able to use those specified versions.

Getting the versions file

First, you'll need to emit a stopover versions YAML file:

  • Create a job that runs stopover
  • Provide that job a valid ATC bearer token (maybe by using fly-github-auth-task)
  • Provide that job metadata about the current build
  • Provide gets to that job, for each resource you want to snapshot. Remember to used passed if required.
  • Invoke stopover, passing in all the above
  • put the resultant file somewhere

An example version-snapshotting job looks like this:

- name: snapshot-versions
  - get : some-repo
    passed: [jobs, that, should, have, passed]
    trigger: true
  - get: resource-we-want-to-track
    passed: [some-test]
  - get: p-another-resource-we-want-to-track
    passed: [another-test]
  - get: bearer-token
  - get: metadata
  - task: generate-versions
    file: config-repo/tasks/generate-versions.yml
      ATC_URL: ((atc_url))
  - put: resource-versions
      file: resources/versions.yml
      acl: private

- name: metadata
  type: build-metadata

The corresponding task is thus:

export ATC_BEARER_TOKEN=$(<bearer-token/bearer-token)
export PIPELINE_NAME=$(<metadata/build-pipeline-name)
stopover ${ATC_URL} team-name ${PIPELINE_NAME} snapshot-versions $(cat metadata/build-name) > resources/versions.yml

Using the versions file

An example job that calls fly set-pipeline on itself:

- name: set-pipeline
  - get: some-repo
    trigger: true
    version: ((resource_version_some-repo))
  - get: upstream-resource-versions
    trigger: true
  - get: bearer-token
  - get: metadata
  - task: fly-set-pipeline
      - name: bearer-token
      - name: some-repo
      - name: metadata
      - name: upstream-resource-versions
        path: /bin/bash
        - -euc
        - |
          export PIPELINE_NAME=$(<metadata/build-pipeline-name)

          # Write bearer token to ~/.flyrc, ommitted for brevity

          fly -t target set-pipeline \
              "$@" \
              --pipeline ${PIPELINE_NAME} \
              --config some-repo/pipeline.yml \
              --load-vars-from some-repo/vars/${PIPELINE_NAME}.yml \
              --load-vars-from upstream-resource-versions/versions.yml \
              --load-vars-from secrets.yml
      - name: resources
      platform: linux
        type: docker-image
          repository: engineerbetter/pcf-ops


To test using saved HTTP requests/responses:

$ ginkgo

We use Hoverfly as a library, which can be set to record or replay. If you need to re-record the HTTP conversation, specify a valid bearer token:

$ ATC_BEARER_TOKEN=foo ginkgo

You can find the bearer token for the ATC you want to test against in your ~/.flyrc file (assuming you're logged in via fly).

You can’t perform that action at this time.