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.

- get: my-repo
  trigger: true
- task: unit
  file: my-repo/ci/unit.yml

Fanning In

If multiple gets are configured with passed constraints, all of the mentioned jobs are correlated. That is, with the following set of inputs:

- 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 puts it back.

- get: version
    bump: minor
    rc: true
- put: version
    version: version/number get step

Fetches a resource, making it available to subsequent steps via the given name.

get: string

Required. The name of the resource once it is fetched. This name satisfies logical inputs to a Task, and may be referenced within the plan itself (e.g. in the file attribute of a task step).

This is also the name of the resource to fetch, if resource is not set.

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.