Resources are the objects that are going to be used
for jobs in the pipeline. They are listed under the
resources key in
the pipeline configuration.
The following example defines a resource representing Concourse's BOSH release repository:
resources: - name: concourse type: git source: uri: https://github.com/concourse/concourse.git branch: master
Any time commits are pushed, the resource will detect them and save new versions of the resource. Any jobs immediately downstream of the resource will then be triggered with the latest version, potentially starting a chain of builds as it makes its way through the pipeline's jobs.
Resources can also be updated via a
put step in
the pipeline's jobs.
Each configured resource consists of the following attributes:
Required. The name of the resource. This should be short and simple. This name will be referenced by build plans of jobs in the pipeline.
Required. The type of the resource. Each worker advertises a mapping
resource-type -> container-image;
type corresponds to the
key in the map.
To see what resource types your deployment supports, check the status of your
worker pool via the
/api/v1/workers API endpoint.
Optional. The location of the resource. This varies by resource type, and is a black box to Concourse; it is blindly passed to the resource at runtime.
git as an example, the source may contain the repo URI, the
branch of the repo to track, and a private key to use when pushing/pulling.
By convention, documentation for each resource type's configuration is
in each implementation's
You can find the source for the resource types provided with Concourse at the Concourse GitHub organization.
1m. The interval on which to check for new
versions of the resource. Acceptable interval options are defined by the
. A list of tags to determine which
workers the checks will be performed on. You'll want to specify this if the
source is internal to a worker's network, for example. See also
tags on a step.
Optional. If specified, web hooks can be sent to trigger an immediate check of the resource, specifying this value as a primitive form of authentication via query params.
After configuring this value, you would then configure your hook sender with the following painfully long path appended to your external URL:
Note that the request payload sent to this API endpoint is entirely ignored. You should configure the resource as if you're not using web hooks, as the resource config is still the "source of truth."