git resource

The following resource definition is an example of the git resource:

name: booklit
type: git
source: {uri: "https://github.com/vito/booklit"}

This could be passed to a job via a get step with trigger: true to run the tests whenever there's new code:

- name: booklit
  type: git
  source: {uri: "https://github.com/vito/booklit"}

- name: unit
  - get: booklit
    trigger: true
  - task: test
    file: booklit/ci/test.yml

time resource

The following resource emits a new version every hour:

name: 1h
type: time
source: {interval: 1h}

This could be passed to a job via a get step with trigger: true to run the job periodically:

- name: 1h
  type: time
  source: {interval: 1h}

- name: nag
  - get: 1h
    trigger: true
  - task: nag
    config: # ...

1.5 Resources

Resources are the heart and soul of Concourse. They represent all external inputs to and outputs of jobs in the pipeline.

Resources are listed under the resources: key in the pipeline configuration. Each configured resource consists of the following fields:

name: string

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.

type: string

Required. The resource type.

icon: string

Optional. The name of a Material Design icon to show next to the resource name in the web UI. For example, github-circle.

source: object

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.

To use 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 README.

You can find the source for the resource types provided with Concourse at the Concourse GitHub organization.

version: object

Optional. A version to pin the resource to across the pipeline. This has the same effect as setting version on every get step referencing the resource.

Resources can also be temporarily pinned to a version via the API and web UI. However this functionality is disabled if the resource is pinned via configuration, and if a pipeline is configured to have a version pinned while also pinned in the web UI, the configuration takes precedence and will clear out the temporary pin.

check_every: string

Optional. Default 1m. The interval on which to check for new versions of the resource. Acceptable interval options are defined by the time.ParseDuration function.

tags: [string]

Optional. Default []. 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 step modifier.

public: boolean

Optional. Default false. If set to true, the metadata for each version of the resource will be viewable by unauthenticated users (assuming the pipeline has been exposed).

Resource metadata should never contain credentials or secret information, but this is off by default just to be safe in case users don't want to show things like commit messages and authors to the public.

Note: even when set to false, the versions identifiers will be visible. In addition, if a resource is fetched in a build whose job is marked public, metadata will be visible in the build output.

webhook_token: string

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."