On this page:
# in_parallel_config schema
# in_parallel step in_parallel
# in_parallel step steps
# in_parallel step limit
# in_parallel step fail_fast
# in_parallel step

1.11.6 in_parallel step

Performs the given steps in parallel. If any sub-steps in a parallel result in a failure or error, the parallel step as a whole is considered to have failed or errored. Expand each section below for more details and examples.

Steps are either configured as a array or within an in_parallel_config schema.

Using the in_parallel step where possible is the easiest way to speeding up a builds.

It is often used to fetch all dependent resources together at the start of a build plan:

jobs:
- name: get-in-parallel
  plan:
  - in_parallel:
    - get: ci
    - get: repo
    - get: code


resources:
- name: repo
  type: mock
- name: code
  type: mock
- name: ci
  type: mock

If any step in the in_parallel fails, the build will fail, making it useful for build matrices:

plan:
- get: some-repo
- in_parallel:
  - task: unit-windows
    file: some-repo/ci/windows.yml
  - task: unit-linux
    file: some-repo/ci/linux.yml
  - task: unit-darwin
    file: some-repo/ci/darwin.yml

in_parallel_config schema

Instead of passing in a list of steps to in_parallel you can pass in the following fields. The list of steps will fall under the steps field.

The steps to perform in parallel.

Using the in_parallel step where possible is the easiest way to speeding up a builds.

It is often used to fetch all dependent resources together at the start of a build plan:

jobs:
- name: get-in-parallel
  plan:
  - in_parallel:
      limit: 2
      fail_fast: false
      steps:
      - get: ci
      - get: repo
      - get: code


resources:
- name: repo
  type: mock
- name: code
  type: mock
- name: ci
  type: mock

Default unlimited. A sempahore which limits the parallelism when executing the steps in a in_parallel step. When set, the number of running steps will not exceed the limit.

When not specified, in_parallel will execute all steps immediately.

Using limit is useful for performing parallel execution of a growing number of tasks without overloading your workers. In the example below, two tasks will be run in parallel and in order until all steps have been executed:

jobs:
- name: limit-in-parallel
  plan:
  - get: examples
  - in_parallel:
      limit: 2
      steps:
      - task: print-date
        file: examples/tasks/print-date.yml
      - task: hello-world
        file: examples/tasks/hello-world.yml
      - task: print-var
        file: examples/tasks/print-var.yml
        vars:
          my-var: hello
          second-var: good-bye


resources:
- name: examples
  type: git
  source:
    uri: https://github.com/concourse/examples.git

Default false. When enabled the parallel step will fail fast by returning as soon as any sub-step fails. This means that running steps will be interrupted and pending steps will no longer be scheduled.