Jobs are listed under the
jobs: key in the pipeline configuration. Each configured job consists of the following fields:
Required. The name of the job. This should be short; it will show up in URLs.
Optional. The old name of the job. If configured, the history of old job will be inherited to the new one. Once the pipeline is set, this field can be removed as the builds have been transfered.
This can be used to rename a job without losing its history, like so:
jobs: - name: new-name old_name: current-name plan: [get: 10m]
After the pipeline is set, because the builds have been inherited, the job can have the field removed:
jobs: - name: new-name plan: [get: 10m]
false. If set to
true, builds will queue up and execute one-by-one, rather than executing in parallel.
Optional. Configures the retention policy for build logs. This is useful if you have a job that runs often but after some amount of time the logs aren't worth keeping around.
The following fields may be specified in
Optional. Keep logs for builds which have finished within the specified number of days.
Optional. Keep logs for the last specified number of builds.
Builds which are not retained by one of the above configurations will have their logs reaped.
The following example will keep logs for any builds that have completed in the last 2 days, while also keeping the last 1000 builds.
jobs: - name: smoke-tests build_log_retention: days: 2 builds: 1000 plan: - get: 10m - task: smoke-tests # ...
Note: if more than 1000 builds finish in the past 2 days, all of them will be retained thanks to the
build_log_retention.days configuration. Similarly, if there are 1000 builds spanning more than 2 days, they will also be kept thanks to the
build_log_retention.builds configuration. Both policies operate independently.
Optional. Deprecated in favor of
Equivalent to the following:
build_log_retention: builds: number
. When set to an array of arbitrary tag-like strings, builds of this job and other jobs referencing the same tags will be serialized.
This can be used to ensure that certain jobs do not run at the same time, like so:
jobs: - name: job-a serial_groups: [some-tag] - name: job-b serial_groups: [some-tag, some-other-tag] - name: job-c serial_groups: [some-other-tag]
In this example,
job-c can run concurrently, but neither job can run builds at the same time as
The builds are executed in their order of creation, across all jobs with common tags.
Optional. If set, specifies a maximum number of builds to run at a time. If
serial_groups are set, they take precedence and force this value to be
false. If set to
true, the build log of this job will be viewable by unauthenticated users. Unauthenticated users will always be able to see the inputs, outputs, and build status history of a job. This is useful if you would like to expose your pipeline publicly without showing sensitive information in the build log.
false. If set to
true, manual triggering of the job (via the web UI or
fly trigger-job) will be disabled.
false. Normally, when a worker is shutting down it will wait for builds with containers running on that worker to finish before exiting. If this value is set to
true, the worker will not wait on the builds of this job. You may want this if e.g. you have a self-deploying Concourse or long-running-but-low-importance jobs.
Optional. Step to execute when the job succeeds. Equivalent to the
on_success step attribute.
Optional. Step to execute when the job fails. Equivalent to the
on_failure step attribute.
Optional. Step to execute when the job aborts. Equivalent to the
on_abort step attribute.