get
step
Fetches a resource, making it available to subsequent steps via the given name.
get: string
resource: string
Optional. Defaults to get
, the name. The resource to fetch, as configured in resources
.
Use this attribute to rename a resource from the overall pipeline context into the job-specific context.
version: ("latest" | "every" | {version})
Optional. Defaults to 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).
passed: [string]
Optional. When specified, only the versions of the resource that made it through the given list of jobs will be considered when triggering and fetching.
params: object
Optional. A map of arbitrary configuration to forward to the resource. Refer to the resource type's documentation to see what it supports.
trigger: boolean
Optional. Default false
. Set to true
to auto-trigger new builds of the plan's job whenever this step has new versions available, as specified by the resource
and any passed
constraints.
Otherwise, if no get
steps set this to true
, the job can only be manually triggered.
Examples
Simple Fetch & Test
Almost every simple unit test job will look something like this: fetch my code with a get
step and run its tests with a task
step.
plan:
- get: my-repo
trigger: true
- task: unit
file: my-repo/ci/unit.yml
Fanning In
If multiple get
s are configured with passed
constraints, all of the mentioned jobs are correlated. That is, with the following set of inputs:
plan:
- get: a
passed: [a-unit, integration]
- get: b
passed: [b-unit, integration]
- get: x
passed: [integration]
This means "give me the versions of a
, b
, and x
that have passed the same build of integration
, with the same version of a
passing a-unit
and the same version of b
passing b-unit
."
This is crucial to being able to implement safe "fan-in" semantics as things progress through a pipeline.
Fetching with params
The following plan fetches a version number via the semver
resource, bumps it to the next release candidate, and put
s it back.
plan:
- get: version
params:
bump: minor
rc: true
- put: version
params:
version: version/number