On this page:
# get step get
# get step resource
# get step passed
# get step params
# get step trigger
# get step version
# get step

1.11.1 get step

Fetches a version of a resource. Expand each section below for more details and examples.

The fetched bits will be registered in the build's artifact namespace under the given identifier. Subsequent task step and put step which list the identifier as an input will have a copy of the bits in their working directory.

Almost every simple job will look something like this: fetch my code with a get step and do something (run tests) with it in a task step.

jobs:
- name: fetch-repo
  plan:
  - get: repo # fetches repo under artifact name "repo"
  - task: ls-repo
    config:
      platform: linux
      image_resource:
        type: mock
        source: {mirror_self: true}
      # pass the "repo" artifact into the task
      inputs:
      - name: repo
      run:
        path: ls
        args: ["-lah","repo"]

resources:
- name: repo
  type: git
  source:
    uri: https://github.com/concourse/examples.git

Defaults to the value of get. The resource to fetch, as configured in pipeline.resources.

Use this attribute to rename a resource from the overall pipeline context into the job-specific context.

jobs:
- name: fetch-repo
  plan:
  - get: thecode # fetches "repo" under artifact name "thecode"
    resource: repo
  - task: ls-repo
    config:
      platform: linux
      image_resource:
        type: mock
        source: {mirror_self: true}
      # pass the "thecode" artifact into the task
      inputs:
      - name: thecode
      run:
        path: ls
        args: ["-lah","thecode"]

resources:
- name: repo
  type: git
  source:
    uri: https://github.com/concourse/examples.git

When specified, only the versions of the resource that made it through the given list of jobs (AND-ed together) will be considered when triggering and fetching.

If multiple gets are configured with passed constraints, all of the mentioned jobs are correlated.

jobs:
- name: lvl-1-firewall
  plan:
  - in_parallel:
    - get: black-ice
    - get: control-node
    - get: cyberdeck

- name: lvl-2-unit
  plan:
  - in_parallel:
    - get: black-ice
      passed: [lvl-1-firewall]
    - get: control-node
      passed: [lvl-1-firewall]
    - get: cyberdeck
      passed: [lvl-1-firewall]

- name: lvl-2-integration
  plan:
  - in_parallel:
    - get: black-ice
      passed: [lvl-1-firewall]
    - get: control-node
      passed: [lvl-1-firewall]
    - get: cyberdeck
      passed: [lvl-1-firewall]

- name: lvl-3-production
  plan:
  - in_parallel:
    - get: black-ice
      passed: [lvl-2-unit,lvl-2-integration]
    - get: control-node
      passed: [lvl-2-unit,lvl-2-integration]
    - get: cyberdeck
      passed: [lvl-2-unit,lvl-2-integration]

resources:
- name: black-ice
  type: mock
  source:
    initial_version: lvl4
- name: control-node
  type: mock
  source:
    initial_version: tower
- name: cyberdeck
  type: mock
  source:
    initial_version: mk3

For the final job, lvl-3-production, only versions that have passed the previous two jobs (lvl-2-unit and lvl-2-integration) will be passed to lvl-3-production.

This is crucial to being able to implement safe "fan-in" semantics as things progress through a pipeline.

Arbitrary configuration to pass to the resource. Refer to the resource type's documentation to see what it supports.

jobs:
- name: resource-params
  plan:
  - get: cyberdeck
    params:
      create_files_via_params:
        version_to_put.txt: "made-via-params"
  - put: cyberdeck
    params:
      file: cyberdeck/version_to_put.txt


resources:
- name: cyberdeck
  type: mock

Default false. If set to true, new builds of the job will be automatically created when a new version for this input becomes available.

Note: if none of a job's get steps are set to true, the job can only be manually triggered.

jobs:
- name: fetch-repo
  plan:
  - get: repo
    trigger: true # automatically runs the job
  - task: ls-repo
    config:
      platform: linux
      image_resource:
        type: mock
        source: {mirror_self: true}
      inputs:
      - name: repo
      run:
        path: ls
        args: ["-lah","repo"]

resources:
- name: repo
  type: git
  source:
    uri: https://github.com/concourse/examples.git

Default latest. The version of the resource to fetch.

If set to latest, scheduling will just find the latest available version of a resource and use it, allowing versions to be skipped. This is usually what you want, e.g. if someone pushes 100 git commits.

If set to every, builds will walk through all available versions of the resource. Note that if passed is also configured, it will only step through the versions satisfying the constraints.

If set to a specific version (e.g. {ref: abcdef123}), only that version will be used. Note that the version must be available and detected by the resource, otherwise the input will never be satisfied. You may want to use fly check-resource to force detection of resource versions, if you need to use an older one that was never detected (as all newly configured resources start from the latest version).