jobs: Plans to execute against resources

Jobs determine the actions of your pipeline, how resources progress through it, and how everything is visualized. They are listed under the jobs key in the pipeline configuration.

The following example defines a simple unit-level job that will trigger whenever new code arrives at the concourse resource:

jobs:
- name: atc-unit
  plan:
  - get: concourse
  - task: unit
    file: concourse/ci/atc.yml

Each configured job consists of the following attributes:

name: string

Required. The name of the job. This should be short; it will show up in URLs.

serial: boolean

Optional. Default false. If set to true, builds will queue up and execute one-by-one, rather than executing in parallel.

Optional. If configured, only the last specified number of builds will have their build logs persisted. This is useful if you have a job that runs periodically but after some amount of time the logs aren't worth keeping around.

Example:

jobs:
- name: smoke-tests
  build_logs_to_retain: 100
  plan:
  - get: 10m
  - task: smoke-tests
    # ...

serial_groups: [string]

Optional. Default []. 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-a and job-c can run concurrently, but neither job can run builds at the same time as job-b.

The builds are executed in their order of creation, across all jobs with common tags.

max_in_flight: integer

Optional. If set, specifies a maximum number of builds to run at a time. If serial or serial_groups are set, they take precedence and force this value to be 1.

public: boolean

Optional. Default 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.

Optional. Default false. If set to true, manual triggering of the job (via the web UI or trigger-job) will be disabled.

interruptible: boolean

Optional. Default 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.

on_success: step

Optional. Step to execute when the job succeeds. Equivalent to the on_success step attribute.

on_failure: step

Optional. Step to execute when the job fails. Equivalent to the on_failure step attribute.

ensure: step

Optional. Step to execute regardless of whether the job succeeds, fails, or errors. Equivalent to the ensure step attribute.

plan: [step]

Required. The Build Plan to execute.