Each resource in a pipeline has a
type. The resource's type determines
what versions are detected, the bits that are fetched when used for a
get step, and the side effect that occurs when used for a
Out of the box, Concourse comes with a few resource types to cover common CI use cases like dealing with Git repositories and S3 buckets.
Beyond these core types, each pipeline can configure its own custom types by
resource_types at the top level. Each custom resource type is
itself defined as a resource that provides the container image for the custom
resource type (see Implementing a Resource). You will almost always
be using the
resource type when doing this.
The following example extends a Concourse pipeline to support use of the
resource type and then uses it within the pipeline:
resource_types: - name: pull-request type: docker-image source: repository: jtarchie/pr resources: - name: atomy-pr type: pull-request source: repo: vito/atomy access_token: ((access-token)) jobs: - name: atomy-pr-unit plan: - get: atomy-pr - put: atomy-pr params: path: atomy-pr status: pending - task: unit file: atomy-pr/ci/unit.yml on_success: put: atomy-pr params: path: atomy-pr status: success on_failure: put: atomy-pr params: path: atomy-pr status: failure
Custom resource types can override the core resource types, and can be defined
in terms of each other. Also, a custom resource type can use the core type that
it's overriding. This is useful if you want to e.g. provide your own custom
docker-image resource, by overriding the core one (and using it one last
time for the override itself), and then using it for all other custom resource
resources, each configured resource type
consists of the following attributes:
Required. The name of the new resource type. This should be short
and simple. This name will be referenced by
resources defined within the same
image_resources used by tasks running in the
Required. The type of the resource used to provide the resource
type's container image. Yes, this is a bit meta. Usually this will be
docker-image, as the resource type must result in a container image,
though there may be other image formats (possibly themselves defined as
custom resource types!).
Optional. The location of the resource type's resource. This varies by resource type, and is a black box to Concourse; it is blindly passed to the resource at runtime.
docker-image as an example, the source would contain something
repository: username/reponame. See the
resource (or whatever resource type your resource type uses) for more
false. If set to
resource's containers will be run with full capabilities, as determined by
the Garden backend the task runs on. For Linux-based backends it typically
determines whether or not the container will run in a separate user
namespace, and whether the
root user is "actual"
root (if set
true) or a user namespaced
root (if set to
This is a gaping security hole; only configure it if the resource type needs it (which should be called out in its documentation). This is not up to the resource type to decide dynamically, so as to prevent privilege escalation via third-party resource type exploits.
. 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.