On this page:
# set_pipeline step set_pipeline
# set_pipeline step file
# set_pipeline step instance_vars
# set_pipeline step vars
# set_pipeline step var_files
# set_pipeline step team
# set_pipeline step

1.11.4 set_pipeline step

Configures a pipeline. Expand each section below for more details and examples.

Pipelines configured with the set_pipeline step are connected to the job that configured them and will be automatically archived in the following scenarios:

  • When the job that previously set a pipeline runs a successful build which did not configure the pipeline (i.e. the set_pipeline step was removed for that specific pipeline).

  • When the job is removed from its pipeline configuration (see job.old_name for renaming instead of removing).

  • When the job's pipeline is archived or destroyed.

This means any job that uses set_pipeline should set all still-desired pipelines in each build, rather than setting them one-by-one through many builds.

See fly archive-pipeline for what happens when a pipeline is archived.

The identifier specifies the name of the pipeline to configure. Unless set_pipeline step team is set, it will be configured within the current team and be created unpaused. If set to self, the current pipeline will update its own config.

set_pipeline: self was introduced in Concourse v6.5.0. It is considered an experimental feature and may be removed at any time. Contribute to the associated discussion with feedback.

This is a way to ensure a pipeline stays up to date with its definition in a source code repository, eliminating the need to manually run fly set-pipeline.

jobs:
- name: set-pipeline
  plan:
  - get: examples
    trigger: true
  - set_pipeline: hello-world  # pipeline's name
    file: examples/pipelines/hello-world.yml  # pipeline's config

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

The path to the pipeline's configuration file.

file points at a .yml file containing the pipeline configuration, which allows this to be tracked with your resources or generated by a task step.

The first segment in the path should refer to another artifact from the plan, and the rest of the path is relative to that artifact.

The get step can be used to fetch your configuration from a git repo and auto-configure it using a set_pipeline step:

jobs:
- name: set-pipeline
  plan:
  - get: examples
    trigger: true
  - set_pipeline: hello-world  # pipeline's name
    file: examples/pipelines/hello-world.yml  # pipeline's config

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

A map of instance vars used to identify instanced pipelines. These vars will also be interpolated into the pipeline config.

Note that variables set with this field will not propagate to tasks configured via task step file. If you want those variables to be determined at the time the pipeline is set, use task step vars as well.

Instance pipelines are experimental and need to be enabled by setting the --enable-pipeline-instances flag on the web node.

The following pipeline will create one instance group with three pipelines. The instance group is called my-bots and each pipeline has a different set of instance_vars making it distinct from the other pipelines in the instance group. 

jobs:
- name: set-pipeline-instance-group
  plan:
  - get: examples
  - in_parallel:
    - set_pipeline: my-bots
      file: examples/pipelines/pipeline-vars.yml
      instance_vars:
        first: initial
        number: "9000"
        hello: HAL
    - set_pipeline: my-bots
      file: examples/pipelines/pipeline-vars.yml
      instance_vars:
        first: second
        number: "3000"
        hello: WALLY-E
    - set_pipeline: my-bots
      file: examples/pipelines/pipeline-vars.yml
      instance_vars:
        first: the-third
        number: "6000"
        hello: R2D2

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

Both instance_vars and vars may be statically. The difference between the two fields is that instance_vars are used to identify a pipeline and render the pipeline config. vars are only used for rendering the pipeline config:

jobs:
- name: set-pipeline-vars-and-instance-vars
  plan:
  - get: examples
  - set_pipeline: my-bots
    file: examples/pipelines/pipeline-vars.yml
    instance_vars:
      first: initial
      number: "9000"
    vars:
      hello: HAL

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

A map of template variables to pass to the pipeline config. Unlike instance_vars, vars are solely used to for interpolation, and do not become a part of the pipeline's identifier.

Note that variables set with this field will not propagate to tasks configured via task step file. If you want those variables to be determined at the time the pipeline is set, use task step vars as well.

jobs:
- name: set-pipeline-vars-only
  plan:
  - get: examples
  - set_pipeline: pipeline-set-with-vars
    file: examples/pipelines/pipeline-vars.yml
    vars:
      first: initial
      number: "9000"
      hello: HAL

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

A list of paths to .yml files that will be passed to the pipeline config in the same manner as the --load-vars-from flag to fly set-pipeline. This means that if a variable appears in multiple files, the value from a file that is passed later in the list will override the values from files earlier in the list.

Where the vars file looks like: 

first: initial
number: "9000"
hello: HAL

And the pipeline config is:

jobs:
- name: set-pipeline-vars-only
  plan:
  - get: examples
  - set_pipeline: pipeline-set-with-vars
    file: examples/pipelines/pipeline-vars.yml
    var_files:
      - examples/pipelines/vars-file.yml

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

By default, the set_pipeline step sets the pipeline for the same team that is running the build.

The team attribute can be used to specify another team.

Only the main team is allowed to set another team's pipeline. Any team other than the main team using the team attribute will error, unless they reference their own team.

The team attribute was introduced in Concourse v6.4.0. It is considered an experimental feature and may be removed at any time. Contribute to the associated discussion with feedback.

jobs:
- name: set-pipeline
  plan:
  - get: examples
    trigger: true
  - set_pipeline: hello-world
    file: examples/pipelines/hello-world.yml
    team: other-team  # name of the team goes here

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